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 2016/11/07 18:11:59 UTC

[jira] [Commented] (KAFKA-4387) KafkaConsumer will enter an infinite loop if the polling thread is interrupted, and either commitSync or committed is called

    [ https://issues.apache.org/jira/browse/KAFKA-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644913#comment-15644913 ] 

Jason Gustafson commented on KAFKA-4387:
----------------------------------------

I think it's reasonable to have KafkaConsumer handle interrupts, but it seems confusing to mix the behavior with wakeup(). It's not that much effort to handle both of them (especially with Java 7 multiple exception catching) and some users may really want to treat them differently. We already have {{org.apache.kafka.common.errors.InterruptException}} which is raised from KafkaProducer, so maybe we could use it instead?

> KafkaConsumer will enter an infinite loop if the polling thread is interrupted, and either commitSync or committed is called
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-4387
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4387
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 0.10.0.1
>            Reporter: Stig Rohde Døssing
>            Assignee: Stig Rohde Døssing
>
> When the KafkaConsumer.commitSync method is called, the ConsumerNetworkClient.poll(RequestFuture<?> future) method will be called with a future that only finishes when the commit request completes, or the request times out.
> When the calling thread is interrupted, every call to the Selector underlying the ConsumerNetworkClient will return immediately, while thread interrupt state is not reset. The call to poll ends up looping until the request timeout, at which point it drops back out to ConsumerCoordinator.commitOffsetsSync which retries the request because TimeoutException is retriable. This repeats indefinitely. 
> For the same reason as in https://issues.apache.org/jira/browse/KAFKA-4375, it is good if the KafkaConsumer can handle interrupts in a reasonable way, rather than having wakeup() be the only way to properly stop a consumer thread.
> I think making ConsumerNetworkClient.maybeTriggerWakeup() throw a WakeupException if the calling thread is interrupted makes sense, since an interrupted thread won't be making progress in polling due to the way Selector works, and KafkaConsumer users then don't have to handle wakeups and interrupts separately.



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