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