[
https://issues.apache.org/jira/browse/KAFKA-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gustafson updated KAFKA-4303:
---
Description:
This appears to be a regression caused by the KIP-62 patch. It is possible that
we end up blocking unnecessarily in {{NetworkClient.poll()}} with no requests
pending. The reason is that {{ConsumerNetworkClient.poll(RequestFuture)}} does
not actually verify that the request has been sent prior to calling
{{NetworkClient.poll()}}. This was not as much of a problem previously because
the maximum timeout was always bounded by the heartbeat interval, which is
typically small.
This appears to be the cause of hanging builds that some people may have
experienced. In particular, I have seen {{ConsumerBounceTest}} hang because of
this problem.
Note that another reason we can block indefinitely in {{commitSync()}} is
coordinator discovery. We do not attempt to fix this here.
was:
This appears to be a regression caused by the KIP-62 patch. It is possible that
we end up blocking indefinitely in {{NetworkClient.poll()}} with no requests
pending. The reason is that {{ConsumerNetworkClient.poll(RequestFuture)}} does
not actually verify that the request has been sent prior to calling
{{NetworkClient.poll()}}. This was not possible previously because the maximum
timeout was always bounded by the heartbeat interval.
This appears to be the cause of hanging builds that some people may have
experienced. In particular, I have seen {{ConsumerBounceTest}} hang because of
this problem.
Note that another reason we can block indefinitely in {{commitSync()}} is
coordinator discovery. We do not attempt to fix this here.
> KafkaConsumer blocks unnecessarily in commitSync()
> ---
>
> Key: KAFKA-4303
> URL: https://issues.apache.org/jira/browse/KAFKA-4303
> Project: Kafka
> Issue Type: Bug
> Components: consumer
>Reporter: Jason Gustafson
>Assignee: Jason Gustafson
>Priority: Blocker
> Fix For: 0.10.1.0
>
>
> This appears to be a regression caused by the KIP-62 patch. It is possible
> that we end up blocking unnecessarily in {{NetworkClient.poll()}} with no
> requests pending. The reason is that
> {{ConsumerNetworkClient.poll(RequestFuture)}} does not actually verify that
> the request has been sent prior to calling {{NetworkClient.poll()}}. This was
> not as much of a problem previously because the maximum timeout was always
> bounded by the heartbeat interval, which is typically small.
> This appears to be the cause of hanging builds that some people may have
> experienced. In particular, I have seen {{ConsumerBounceTest}} hang because
> of this problem.
> Note that another reason we can block indefinitely in {{commitSync()}} is
> coordinator discovery. We do not attempt to fix this here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
