kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-3817) KTableRepartitionMap should handle null inputs
Date Thu, 04 Aug 2016 08:40:20 GMT

    [ 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:


    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:


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.filipiak@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:
>            Reporter: Jeff Klukas
>            Assignee: Guozhang Wang
>             Fix For:
> 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

View raw message