curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: DEVS PLEASE READ: What is the correct timeout for a session
Date Mon, 14 Sep 2015 05:24:08 GMT
Good point, either way it probably needs to be documented, as it would 
probably be confusing to get a session loss event from Curator and then 
manage to reconnect to ZK and still find all your sessions ephemeral nodes 
present. 
True. What should we do? Leave it as is?

I presume it's not possible to get a hook into the acknowledgement of an 
event from ZK? We could use that as the start of the session timeout timer. 
Even if we could, the important stuff happens on the server so it’s moot. 





On September 13, 2015 at 11:42:16 PM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:

Good point, either way it probably needs to be documented, as it would  
probably be confusing to get a session loss event from Curator and then  
manage to reconnect to ZK and still find all your sessions ephemeral nodes  
present.  

I presume it's not possible to get a hook into the acknowledgement of an  
event from ZK? We could use that as the start of the session timeout timer.  

On Mon, Sep 14, 2015 at 2:39 PM, Jordan Zimmerman <  
jordan@jordanzimmerman.com> wrote:  

> Not sure if this is an issue or not. It's better that Curator declares a  
> session lost a bit later than a bit earlier than ZK.  
> Actually, I was thinking it would be better if Curator declares lost  
> before ZK does. The idea is to wait until the last moment to stop locks,  
> etc. But, users would still want to not have two processes thinking they  
> own the same lock. I wonder if we need to add a “fudge factor” of some kind  
> so that Curator fakes the session loss a bit before the negotiated session  
> timeout elapses.  
>  
>  
>  
> -JZ  
>  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message