[
https://issues.apache.org/jira/browse/KAFKA-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232663#comment-15232663
]
Jason Gustafson commented on KAFKA-3470:
----------------------------------------
I think this makes sense. In some situations that I've seen in testing with the
Java client, when replication of offset commits is slow (e.g. because of a
broker failure), you can get a couple commits effectively blocking out
heartbeats. Eventually when the heartbeat gets through, you may find that the
group has already begun rebalancing. So treating commits as heartbeats closes
the window a little bit for such failures. It also seems intuitive to treat
commits as an indication of consumer liveness. I'll go ahead and submit a patch
today.
> Consumer group coordinator should take commit requests as effective as
> heartbeats
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-3470
> URL: https://issues.apache.org/jira/browse/KAFKA-3470
> Project: Kafka
> Issue Type: Improvement
> Reporter: Zaiming Shi
>
> Group coordinator does not reset heartbeat timer when commit request is
> received.
> This may lead to unnecessary session timeouts when a consumer sends
> sync commit requests so frequently that causes heartbeat requests to be
> delayed.
> Presumably (as I do not know Kafka code well):
> Commit requests (v1 and v2) have all data fields for a heartbeat request,
> If they are taken as effective as heartbeat requests, we should have
> better group stability.
> [For reference]
> previous discussions in: [email protected]
> mail title: consumer group, why commit requests are not considered as
> effective heartbeats?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
