kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KAFKA-4387) KafkaConsumer will enter an infinite loop if the polling thread is interrupted, and either commitSync or committed is called
Date Wed, 30 Nov 2016 04:22:59 GMT

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

ASF GitHub Bot commented on KAFKA-4387:
---------------------------------------

Github user asfgit closed the pull request at:

    https://github.com/apache/kafka/pull/2110


> 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
>             Fix For: 0.10.2.0
>
>
> 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)

Mime
View raw message