Description
This can be easily reproduced as following:
{
...
consumer.assign(SomeNonExsitingTopicParition);
consumer.position();
...
}
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.
Attachments
Issue Links
- duplicates
-
KAFKA-3503 Throw exception on missing/non-existent partition
-
- Resolved
-
- is related to
-
KAFKA-2391 Blocking call such as position(), partitionsFor(), committed() and listTopics() should have a timeout
-
- Resolved
-
-
KAFKA-3727 Consumer.poll() stuck in loop on non-existent topic manually assigned
-
- Resolved
-
- links to
