curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Jaton <bja...@radiantlogic.com>
Subject Re: Curator connection states
Date Fri, 16 Jan 2015 19:05:51 GMT
Yes, I will open a JIRA for this.

Regarding my original email, it is normal that the background retry goes on
for longer than the LOST event?

On Thu, Jan 15, 2015 at 2:52 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> Yeah. If Curator itself can be altered to support it, please send a PR.
> Even if not, send a PR as this might be useful to others.
>
> -JZ
>
>
>
> On January 15, 2015 at 5:51:01 PM, Benjamin Jaton (bjaton@radiantlogic.com)
> wrote:
>
> Instead of that, I think I am going to implement a custom event for the
> session loss that will be trigger either:
> - sessionTimeoutMs after the last SUSPENDED event (if no RECONNECTED event
> has been received)
> - on a RECONNECTED event if the new session ID is different from the old
> one.
>
> It's a little hacky but that should probably do the trick to have a timely
> notification that the session has been lost.
>
> What do you think?
>
> On Thu, Jan 15, 2015 at 10:31 AM, Benjamin Jaton <bjaton@radiantlogic.com>
> wrote:
>
>> Ah thanks for the tip, I'm definitely going to try that.
>>
>> On Thursday, January 15, 2015, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>>  NOTE: You can also set a main watcher that watches for session
>>> expiration.
>>>
>>>  -JZ
>>>
>>>
>>>
>>> On January 15, 2015 at 11:39:53 AM, Jordan Zimmerman (
>>> jordan@jordanzimmerman.com) wrote:
>>>
>>>   LOST was never intended to match session loss. Session loss is only
>>> detected by ZooKeeper once the connection is re-established.
>>>
>>>  -JZ
>>>
>>>
>

Mime
View raw message