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