[
https://issues.apache.org/jira/browse/KAFKA-3817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407425#comment-15407425
]
ASF GitHub Bot commented on KAFKA-3817:
---------------------------------------
GitHub user Kaiserchen opened a pull request:
https://github.com/apache/kafka/pull/1705
KAFKA-3817: KTableRepartitionMap publish old Change first, for non-count
aggregates
I affirm that the contribution is my original work and that I license the
work to the project under the project's open source license.
This cleans up misbehaviour that was introduce while fixing KAFKA-3817. It
is impossible for a non-count aggregate to be build, when the addition happens
before the removal. IMHO making sure that these details are correct is very
important.
This PR has local test errors. It somehow fails the ResetIntegrationTest.
It doesn't quite appear to me why but it looks like this PR breaks it,
especially because the error appears with the ordering of the events. Still I
am unable to find where I could have broken it. Maybe not seems to fail on
trunk aswell.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Kaiserchen/kafka
KAFKA-3817-preserve-order-for-aggreagators
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/1705.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1705
----
commit efb8c4b9ff1dbef8bcf874b66a228756dd017c76
Author: jfilipiak <jan.filip...@trivago.com>
Date: 2016-08-04T08:23:43Z
KTableRepartitionMap publish old Change first, for non-count aggregates
----
> 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)
