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

Jason Gustafson commented on KAFKA-3822:
----------------------------------------

[~singhashish] Yeah, that might make the most sense. On the other hand, there 
are already quite a lot of configurations for the consumer, so I'm curious how 
people feel about overloading. The producer is also kind of a weird mix. It has 
both {{max.block.ms}} and a close() which accepts a timeout. Was there a reason 
close() needed to be treated differently? In any case, I think it's time to do 
a KIP to collect wider feedback since this is one of the common problems users 
face with the consumer.

> Kafka Consumer close() hangs indefinitely if Kafka Broker shutdown while 
> connected
> ----------------------------------------------------------------------------------
>
>                 Key: KAFKA-3822
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3822
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 0.9.0.1, 0.10.0.0
>         Environment: x86 Red Hat 6 (1 broker running zookeeper locally, 
> client running on a separate server)
>            Reporter: Alexander Cook
>            Assignee: Ashish K Singh
>
> I am using the KafkaConsumer java client to consume messages. My application 
> shuts down smoothly if I am connected to a Kafka broker, or if I never 
> succeed at connecting to a Kafka broker, but if the broker is shut down while 
> my consumer is connected to it, consumer.close() hangs indefinitely. 
> Here is how I reproduce it: 
> 1. Start 0.9.0.1 Kafka Broker
> 2. Start consumer application and consume messages
> 3. Stop 0.9.0.1 Kafka Broker (ctrl-c or stop script)
> 4. Try to stop application...hangs at consumer.close() indefinitely. 
> I also see this same behavior using 0.10 broker and client. 
> This is my first bug reported to Kafka, so please let me know if I should be 
> following a different format. Thanks! 



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

Reply via email to