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 > > > > >
