Benjamin Reed commented on ZOOKEEPER-922:

camille, i also think disabling moving sessions is not a good idea or very 
useful, but it seems to be the only way to have sensible semantics. 

may i suggest that we take this discussion a bit higher? i think there are 
fundamental assumptions that you are making that i'm questioning. can you write 
up a high-level design and state your assumptions? i can't quite see how the 
math works out between the client-server timeouts, connect timeouts, and lower 
session timeout. i'm also not clear on how much you are relying on a connection 
reset for the failure detection.

> enable faster timeout of sessions in case of unexpected socket disconnect
> -------------------------------------------------------------------------
>                 Key: ZOOKEEPER-922
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-922
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: server
>            Reporter: Camille Fournier
>            Assignee: Camille Fournier
>             Fix For: 3.4.0
>         Attachments: ZOOKEEPER-922.patch
> In the case when a client connection is closed due to socket error instead of 
> the client calling close explicitly, it would be nice to enable the session 
> associated with that client to time out faster than the negotiated session 
> timeout. This would enable a zookeeper ensemble that is acting as a dynamic 
> discovery provider to remove ephemeral nodes for crashed clients quickly, 
> while allowing for a longer heartbeat-based timeout for java clients that 
> need to do long stop-the-world GC. 
> I propose doing this by setting the timeout associated with the crashed 
> session to "minSessionTimeout".

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to