Sounds good, thanks for the clarification. Jan
On 17 June 2015 at 22:09, Jason Gustafson <ja...@confluent.io> wrote: > We have a couple open tickets to address these issues (see KAFKA-1894 and > KAFKA-2168). It's definitely something we want to fix. > > On Wed, Jun 17, 2015 at 4:21 AM, Jan Stette <jan.ste...@gmail.com> wrote: > >> Adding some more details to the previous question: >> >> The indefinite wait doesn't happen on calling subscribe() on the consumer, >> it happens when I (in this case) call seekToEnd(). >> >> A related problem to this is that the seekToEnd() method is synchronized >> (as are the other access methods on KafkaConsumer), so the client holds a >> lock while sitting in this wait. This means that if another thread tries >> to call close(), which is all synchronized, this thread will also be >> blocked. >> >> Holding locks while performing network I/O seems like a bad idea - is this >> something that's planned to be fixed? >> >> Jan >> >> >> >> On 17 June 2015 at 10:31, Jan Stette <jan.ste...@gmail.com> wrote: >> >> > I'm trying out the new KafkaConsumer client API in the trunk of the >> source >> > tree, and while I realise that this is a work in progress, I have a >> > question that perhaps someone can shed some light on. >> > >> > I'm looking at how to handle various error scenarios for a Kafka client, >> > in particular what happens when trying to connect to the broker but it's >> > not available. The behaviour I'm seeing is that the client will retry >> > indefinitely (at the configurable interval), basically looping around in >> > Fetcher.awaitMetadataUpdate() forever. >> > >> > I would like to have some way to fail the connection attempt to avoid >> the >> > calling thread being blocked forever. Is this possible with the current >> > version of the client? (Snapshot as of 16/6/15). If not, is that >> something >> > that's planned for the future? >> > >> > Jan >> > >> > >> > >
