You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Jason Gustafson (JIRA)" <ji...@apache.org> on 2015/07/17 03:50:04 UTC
[jira] [Updated] (KAFKA-2343) Clarify KafkaConsumer.poll rebalance behavior

     [ https://issues.apache.org/jira/browse/KAFKA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Gustafson updated KAFKA-2343:
-----------------------------------
    Description: 
The current javadoc for KafkaConsumer.poll says the following:

{code}
     * The offset used for fetching the data is governed by whether or not {@link #seek(TopicPartition, long)} is used.
     * If {@link #seek(TopicPartition, long)} is used, it will use the specified offsets on startup and on every
     * rebalance, to consume data from that offset sequentially on every poll. If not, it will use the last checkpointed
     * offset using {@link #commit(Map, CommitType) commit(offsets, sync)} for the subscribed list of partitions.
{code}

Unless I am misreading, this suggests that rebalance should reset to the seeked position (if one was set). The consumer definitely doesn't do this currently, so we should either fix the javadoc if that is not the desired behavior or fix the code.

  was:
The current javadoc for KafkaConsumer.poll says the following:

     * The offset used for fetching the data is governed by whether or not {@link #seek(TopicPartition, long)} is used.
     * If {@link #seek(TopicPartition, long)} is used, it will use the specified offsets on startup and on every
     * rebalance, to consume data from that offset sequentially on every poll. If not, it will use the last checkpointed
     * offset using {@link #commit(Map, CommitType) commit(offsets, sync)} for the subscribed list of partitions.

Unless I am misreading, this suggests that rebalance should reset to the seeked position (if one was set). The consumer definitely doesn't do this currently, so we should either fix the javadoc if that is not the desired behavior or fix the code.


> Clarify KafkaConsumer.poll rebalance behavior
> ---------------------------------------------
>
>                 Key: KAFKA-2343
>                 URL: https://issues.apache.org/jira/browse/KAFKA-2343
>             Project: Kafka
>          Issue Type: Bug
>            Reporter: Jason Gustafson
>
> The current javadoc for KafkaConsumer.poll says the following:
> {code}
>      * The offset used for fetching the data is governed by whether or not {@link #seek(TopicPartition, long)} is used.
>      * If {@link #seek(TopicPartition, long)} is used, it will use the specified offsets on startup and on every
>      * rebalance, to consume data from that offset sequentially on every poll. If not, it will use the last checkpointed
>      * offset using {@link #commit(Map, CommitType) commit(offsets, sync)} for the subscribed list of partitions.
> {code}
> Unless I am misreading, this suggests that rebalance should reset to the seeked position (if one was set). The consumer definitely doesn't do this currently, so we should either fix the javadoc if that is not the desired behavior or fix the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)