[ https://issues.apache.org/jira/browse/KAFKA-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16062770#comment-16062770 ]
Michal Borowiecki edited comment on KAFKA-4750 at 6/26/17 8:42 AM: ------------------------------------------------------------------- Deserialiser.deserialize javadoc says: * @param data serialized bytes; may be null; implementations are recommended to handle null by +returning a value+ or null rather than throwing an exception. If it's fair for deserializer to return a value when a null byte array is provided, by symmetry, the serializer should be able to return null when such an object is provided and achieve correct round-tripping. [~evis] In your example, whether its intuitive or not I guess it depends on peoples' intuition. To me it is intuitive, since null on a changelog topic is a tombstone marker. If I serialize a value to null then to me it's intuitive that it's equivalent to deletion, so should not be found in the following get. An example use case would be if the value types are collections. In order to avoid dealing with nulls in the application layer, one might want to deserialize null into an empty collection and vice-versa. Would that be a valid use-case? I can't see why not, but I may be wrong. was (Author: mihbor): Deserialiser.deserialize javadoc says: * @param data serialized bytes; may be null; implementations are recommended to handle null by +returning a value+ or null rather than throwing an exception. If it's fair for deserializer to return a value when a null byte array is provided, by symmetry, the serializer should be able to return null when such an object is provided and achieve correct round-tripping. [~evis] In your example, whether its intuitive or not I guess it depends on peoples' intuition. To me it is intuitive, since null on a changelog topic is a tombstone marker. If I serialize a value to null then it's intuitive that it's equivalent to deletion. An example use case would be if the value types are collections. In order to avoid dealing with nulls in the application layer, one might want to deserialize null into an empty collection and vice-versa. Would that be a valid use-case? I can't see why not, but I may be wrong. > KeyValueIterator returns null values > ------------------------------------ > > Key: KAFKA-4750 > URL: https://issues.apache.org/jira/browse/KAFKA-4750 > Project: Kafka > Issue Type: Bug > Components: streams > Affects Versions: 0.10.1.1, 0.11.0.0, 0.10.2.1 > Reporter: Michal Borowiecki > Assignee: Evgeny Veretennikov > Labels: newbie > Attachments: DeleteTest.java > > > The API for ReadOnlyKeyValueStore.range method promises the returned iterator > will not return null values. However, after upgrading from 0.10.0.0 to > 0.10.1.1 we found null values are returned causing NPEs on our side. > I found this happens after removing entries from the store and I found > resemblance to SAMZA-94 defect. The problem seems to be as it was there, when > deleting entries and having a serializer that does not return null when null > is passed in, the state store doesn't actually delete that key/value pair but > the iterator will return null value for that key. > When I modified our serilizer to return null when null is passed in, the > problem went away. However, I believe this should be fixed in kafka streams, > perhaps with a similar approach as SAMZA-94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)