If we do that, shouldn't `max.poll.records` remain with the current default
of `Integer.MAX_VALUE`?

On Sat, Jun 18, 2016 at 5:18 PM, Jay Kreps <j...@confluent.io> wrote:

> +1
>
> One small but important thing I think we should consider changing: I think
> we should consider setting the default for max.poll.interval to infinite.
> Previously our definition of alive was "polls within session timeout". Now
> our definition of alive is "pings from b/g thread w/in session timeout".
> The reality is that anything we set here as a default is going to be too
> low for some people and those people will be confused. Previously that was
> okay because the definition of liveness required you to understand and
> think about this setting, so getting an error meant you needed to think
> harder. But now this is really an optional setting for people who care to
> enforce some bound, so introducing a possible failure/instability mode by
> guess that bound seems wrong. Instead I think users that know and care
> about this should set a thoughtful max.poll.interval, but we should not try
> to guess for those who don't.
>
> This seems minor but I think we've found that defaults matter more than
> configs so it's worth being thoughtful.
>
> -Jay
>
> On Thu, Jun 16, 2016 at 11:44 AM, Jason Gustafson <ja...@confluent.io>
> wrote:
>
> > Hi All,
> >
> > I'd like to open the vote for KIP-62. This proposal attempts to address
> one
> > of the recurring usability problems that users of the new consumer have
> > faced with as little impact as possible. You can read the full details
> > here:
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-62%3A+Allow+consumer+to+send+heartbeats+from+a+background+thread
> > .
> >
> > After some discussion on this list, I think we were in agreement that
> this
> > change addresses a major part of the problem and we've left the door open
> > for further improvements, such as adding a heartbeat() API or a
> separately
> > configured rebalance timeout. Thanks in advance to everyone who helped
> > review the proposal.
> >
> > -Jason
> >
>

Reply via email to