[
https://issues.apache.org/jira/browse/KAFKA-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731052#comment-14731052
]
Jay Kreps commented on KAFKA-2397:
----------------------------------
Couple thoughts:
1. [~hachikuji] Does this need to be in the next release? This is really an
optimization we can do at any time right? How bad of a user experience is it
not to have it?
2. Does anyone have a concrete idea of where using TCP close to signal
disconnect falls short? [~becket_qin] I think you are saying this is a problem
but when is it actually a problem? This might be one where broader input could
help...
3. We shouldn't end up with two different ways to do the same thing just
because two ways have been proposed and we aren't sure yet which is best. This
just means we aren't done thinking through the design. I think likely zero is
better than two, right?
> leave group request
> -------------------
>
> Key: KAFKA-2397
> URL: https://issues.apache.org/jira/browse/KAFKA-2397
> Project: Kafka
> Issue Type: Sub-task
> Components: consumer
> Reporter: Onur Karaman
> Assignee: Onur Karaman
> Priority: Minor
> Fix For: 0.8.3
>
>
> Let's say every consumer in a group has session timeout s. Currently, if a
> consumer leaves the group, the worst case time to stabilize the group is 2s
> (s to detect the consumer failure + s for the rebalance window). If a
> consumer instead can declare they are leaving the group, the worst case time
> to stabilize the group would just be the s associated with the rebalance
> window.
> This is a low priority optimization!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
