Description
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.
Attachments
Issue Links
- relates to
-
KAFKA-1894 Avoid long or infinite blocking in the consumer
-
- Resolved
-
- links to
