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

Guozhang Wang commented on KAFKA-3177:
--------------------------------------

[~hachikuji] Just checking, this infinite loop's pattern is not the same as the 
scenario when there is no broker up and running, which will fall in the loop of 
finding the coordinator and disconnected from the given socket, right?

It seems today we have a couple of patterns that could result it "not 
respecting timeout in poll" and "unexpected blocking for unblocking functions", 
it would be better to fix these two in a more generic way rather tackling them 
one-by-one?

> Kafka consumer can hang when position() is called on a non-existing partition.
> ------------------------------------------------------------------------------
>
>                 Key: KAFKA-3177
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3177
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 0.9.0.0
>            Reporter: Jiangjie Qin
>            Assignee: Jiangjie Qin
>             Fix For: 0.9.0.1
>
>
> This can be easily reproduced as following:
> {code}
> {
>     ...
>     consumer.assign(SomeNonExsitingTopicParition);
>     consumer.position();
>     ...
> }
> {code}
> It seems when position is called we will try to do the following:
> 1. Fetch committed offsets.
> 2. If there is no committed offsets, try to reset offset using reset 
> strategy. in sendListOffsetRequest(), if the consumer does not know the 
> TopicPartition, it will refresh its metadata and retry. In this case, because 
> the partition does not exist, we fall in to the infinite loop of refreshing 
> topic metadata.
> Another orthogonal issue is that if the topic in the above code piece does 
> not exist, position() call will actually create the topic due to the fact 
> that currently topic metadata request could automatically create the topic. 
> This is a known separate issue.



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

Reply via email to