[
https://issues.apache.org/jira/browse/KAFKA-4387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644936#comment-15644936
]
Stig Rohde Døssing commented on KAFKA-4387:
-------------------------------------------
Fine by me. I'll make a PR for it shortly
> 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)
