[
https://issues.apache.org/jira/browse/KAFKA-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405568#comment-15405568
]
Jan Filipiak commented on KAFKA-3817:
-------------------------------------
[~guozhang]
So the ability to handle null values in the repartition map processor is really
important. Nevertheless, I fear that this fix introduced a major problem
regarding the ordering of the events. We talked about this
https://github.com/apache/kafka/blob/ba9456de2ebf1a34bdf5f6f62a701875822e1923/streams/src/main/java/org/apache/kafka/streams/kstream/internals/KTableAggregate.java#L82
before, but with this change a downstream KTableAggregate does not stand a
chance to keep this behaviour. The mapper might change the key of the record,
but that is not guaranteed to happen. So the KTableAggregate will not remove
first and then add the new, but it will add the new and remove then. This is
okay for counting (one might see negativ values(might be a problem when Serde
only handles unsigned)) but its gameover for building complex type objects.
I would propose to change the order of the 2 if clauses that are now present
here:
https://github.com/apache/kafka/blob/730bf9a37a08b2ca41dcda52d2c70e92e85980f7/streams/src/main/java/org/apache/kafka/streams/kstream/internals/KTableRepartitionMap.java#L83
that should fix it.
> KTableRepartitionMap should handle null inputs
> ----------------------------------------------
>
> Key: KAFKA-3817
> URL: https://issues.apache.org/jira/browse/KAFKA-3817
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 0.10.0.0
> Reporter: Jeff Klukas
> Assignee: Guozhang Wang
> Fix For: 0.10.0.1
>
>
> When calling {{KTable.groupBy}} on the result of a KTable-KTable join, NPEs
> are raised:
> {{org.apache.kafka.streams.kstream.internals.KTableRepartitionMap$
> > KTableMapProcessor.process(KTableRepartitionMap.java:88)}}
> The root cause is that the join is expected to emit null values when no match
> is found, but KTableRepartitionMap is not set up to handle this case.
> On the users email list, [~guozhang] described a plan of action:
> I think this is actually a bug in KTableRepartitionMap
> that it actually should expect null grouped keys; this would be a
> straight-forward fix for this operator, but I can make a pass over all the
> repartition operators just to make sure they are all gracefully handling
> null keys.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
