STORM-2265: Incorrectly Serialized JSON in TransactionalState causes Worker to Die

[hmcl]

No description provided.

[HeartSaVioR]

@hmcl
I filed STORM-2264, and thought about this approach before.

This approach makes GlobalPartitionInformation serialized well, but the type is lost when deserializing. Deserialized object is not GlobalPartitionInformation.
I haven't deeply look into storm-kafka Trident implementation so hard to guess how this affects.

If we're not sure, just replacing JSONValue.parseWithException to JSONValue.parse only from TransactionalState rolls back the problem. It's just hiding an long ago issue again so need to find out clearer way but given that it is critical, we may need quick fix first.

[hmcl]

@HeartSaVioRJSONValue.parse will simply return null if there is a serialization exception. How can that be better than this approach? Isn't anything other than null better than null?

[HeartSaVioR]

@hmcl
What I'm saying is, given that we've had no issue regarding this and we don't have clear and safe approach, it would be better to roll back to previous.

Two things should be clear:

1. What's the type of deserialized value of GlobalPartitionInformation? (Please note that JSONValue doesn't guarantee restoring origin type.)
2. Is it guaranteed for all the paths to use the value from TransactionalState as that type?

And there's compile failure on your change. Please check the Travis CI result.

[hmcl]

@HeartSaVioR I agree with you. Let's merge STORM-2264 and keep this open to explore a more compelling fix. If we find out that the work around the Stream API will make this fix unnecessary, we can then close this PR and the associated JIRA.