Re: Debugging Kafka Streams Windowing

[Garrett Barton <ga...@gmail.com>]

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.kariya@go-jek.com> wrote:

> On 22 May 2017 at 16:09, Guozhang Wang <wa...@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.
>

Re: Debugging Kafka Streams Windowing

[Mahendra Kariya <ma...@go-jek.com>]

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 <ga...@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.kariya@go-jek.com> wrote:
>
> > On 22 May 2017 at 16:09, Guozhang Wang <wa...@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.
> >
>