Yes. To some extent. But the rebalancing is now taking a lot of time. There are situations where we have to manually restart the Streams app because rebalancing is kind of "stuck" for several minutes.
On 7 June 2017 at 06:28, Garrett Barton <garrett.bar...@gmail.com> wrote: > Mahendra, > > Did increasing those two properties do the trick? I am running into this > exact issue testing streams out on a single Kafka instance. Yet I can > manually start a consumer and read the topics fine while its busy doing > this dead stuffs. > > On Tue, May 23, 2017 at 12:30 AM, Mahendra Kariya < > mahendra.kar...@go-jek.com> wrote: > > > On 22 May 2017 at 16:09, Guozhang Wang <wangg...@gmail.com> wrote: > > > > > For > > > that issue I'd suspect that there is a network issue, or maybe the > > network > > > is just saturated already and the heartbeat request / response were not > > > exchanged in time between the consumer and the broker, or the sockets > > being > > > dropped because of socket limit. Under this cases not all consumers may > > be > > > affected, but since the associated issue is from "AbstractCoordinator" > > > class which is part of the consumer client, I'd still be surprised if > it > > is > > > actually due to Streams itself with the same consumer config settings, > > but > > > not to consumers. > > > > > > > Yes. This is the conclusion that even we are coming to after further > > investigation. But didn't want to post it here until we were sure. > > > > We are experimenting with increasing the default timeouts, particularly > > hearbeat.interval.ms and session.timeout.ms. So far, the things have > been > > running fine. But we will let it run for a few more days before closing > > this issue. > > >
