[
https://issues.apache.org/jira/browse/KAFKA-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696327#comment-14696327
]
Ewen Cheslack-Postava commented on KAFKA-2397:
----------------------------------------------
Can we be more concrete about what we think the odd side effects would be if it
were tied to the TCP session? What would happen that would cause the TCP
connection to actually close rather than waiting around for a long time for the
normal TCP timeout? I'm struggling to come up with a scenario that would
actually kill the connection and I wouldn't want to kick the member out of the
group.
I'm running into annoying issues since we don't have any mechanism to leave the
group currently. Initially it was just manifesting in my manual testing with
Copycat where if I restarted a sink task, it would take awhile for it to start
processing data because it had to wait for the process that I had just killed
to be kicked out of the group. This is a bit annoying with the default session
timeout of 30s, but workable. However, I'm also working on system tests and now
it's making me set quite large timeouts for some steps (which otherwise should
be more like < 1s to complete) and therefore makes the tests run a lot slower.
> 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)
