[
https://issues.apache.org/jira/browse/KAFKA-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812848#comment-16812848
]
Guozhang Wang commented on KAFKA-4600:
--------------------------------------
[~braedon] I think your argument makes sense. But we still need to define, that
when such exception gets thrown to user's face from `consumer.poll` call, and
users decide to continue and retry instead of shutting down the consumer, what
should happen -- back to my example above, as in option 2), how to treat
partitions that failed in revocation / assignment.
So how about this: let me piggy-back this proposal along with KIP-429 since it
will change the behavior of revocation and assignment orderings anyways. After
I'm done adding a section regarding the error handling I'll ping you on this
ticket and we can continue our discussion to fix it in the next release.
> Consumer proceeds on when ConsumerRebalanceListener fails
> ---------------------------------------------------------
>
> Key: KAFKA-4600
> URL: https://issues.apache.org/jira/browse/KAFKA-4600
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Affects Versions: 0.10.1.1
> Reporter: Braedon Vickers
> Priority: Major
>
> One of the use cases for a ConsumerRebalanceListener is to load state
> necessary for processing a partition when it is assigned. However, when
> ConsumerRebalanceListener.onPartitionsAssigned() fails for some reason (i.e.
> the state isn't loaded), the error is logged and the consumer proceeds on as
> if nothing happened, happily consuming messages from the new partition. When
> the state is relied upon for correct processing, this can be very bad, e.g.
> data loss can occur.
> It would be better if the error was propagated up so it could be dealt with
> normally. At the very least the assignment should fail so the consumer
> doesn't see any messages from the new partitions, and the rebalance can be
> reattempted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
