[
https://issues.apache.org/jira/browse/KAFKA-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646338#comment-14646338
]
Jason Gustafson commented on KAFKA-2382:
----------------------------------------
[~ewencp] I could be wrong, but I think the code currently throws
IllegalArgumentException when you call seek for unassigned partitions. It's a
little obscure since the exceptions aren't thrown from seek() directly, but
from fetched() and consumed(). I think this is clarified a little in my PR for
KAFKA-2350, if you want to have a look.
> KafkaConsumer seek methods should throw an exception when called for
> partitions not assigned to this consumer instance
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-2382
> URL: https://issues.apache.org/jira/browse/KAFKA-2382
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Reporter: Ewen Cheslack-Postava
> Assignee: Neha Narkhede
> Fix For: 0.8.3
>
>
> It looks like the current code for the consumer will blindly accept any seek
> calls, adding the offests to SubscriptionState. If the consumer is being used
> in simple consumer mode, this makes sense, but when using subscriptions & the
> consumer coordinator, this should be an error.
> If a user accidentally invokes the seek at the wrong time, it will just get
> lost. As a simple example, if you start the consumer, subscribe, and then
> immediately seek, that seek will just get lost as soon as you call poll() and
> the initial join group + rebalance occurs. That sequence of calls simply
> shouldn't be valid since it doesn't make sense to seek() on a partition you
> haven't been assigned.
> Relatedly, I think the current effect of doing this can result in incorrect
> behavior because SubscriptionState.hasAllFetchedPositions() only checks the
> size of the fetched map and assignedPartitions map. Since this bug allows
> adding arbitrary topic partitions to the fetched map, that check is not
> accurate.
> This is probably related to KAFKA-2343, but that one is just a doc fix on how
> seek is supposed to behave wrt poll and rebalance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)