Camille Fournier commented on ZOOKEEPER-922:

That is a valid concern. For the system I am implementing, I would rather 
aggressively time out connections I believe to be closed with the risk of 
occasionally hitting this particular edge case (my client can automatically 
re-connect and re-establish its ephemeral data if necessary), but it's worth 
thinking about whether it is possible to avoid.
I realize the extreme end of this argument is just to set the session timeout 
lower and let the gc-ing clients re-establish their state but I want the best 
of both worlds.

> 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