curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikrant Singh <vikrant.subscr...@gmail.com>
Subject Re: Query on SESSION_LOST (3.0.0)
Date Thu, 19 Nov 2015 18:12:32 GMT
It seems from release notes that this change (3.0.0) will work only with
3.5.x of zookeeper. As 3.5.x is still not a stable version (for quite some
time its in alpha).. what is recommendation for a curator user.

Is 3.5.x not astable enough to mark as stable release ? What are
recommendation for curator used who need to leverage the fix in 3.4.x world
?

On Wed, Nov 18, 2015 at 3:29 PM, Vikrant Singh <vikrant.subscribe@gmail.com>
wrote:

> Got it. Thanks for explaining it.
> As I was killing  the process (assuming zookeeper removed the node), this
> change will help my to save some restarts which were not needed.
>
> On Wed, Nov 18, 2015 at 3:23 PM, Cameron McKenzie <cammckenzie@apache.org>
> wrote:
>
>> Not necessarily false alarms, just that the LOST event didn't necessarily
>> mean session loss, just that curator was giving up.
>>
>> With 3.0.0 the LOST event will occur when Curator is explicitly told that
>> a session has expired by Zookeeper, or if no connection to Zookeeper is
>> available, Curator will publish a LOST event when it thinks that the
>> session has been lost. This is based on a timer and the negotiated session
>> timeout with ZooKeeper.
>>
>>
>>
>> On Thu, Nov 19, 2015 at 10:13 AM, Vikrant Singh <
>> vikrant.subscribe@gmail.com> wrote:
>>
>>> Thanks a lot for reply. So if I am understanding it correct, there were
>>> false alarms (or mistaken connection lost) . With 3.0.0 connection_lost
>>> events will happen only when there is true session lost.
>>>
>>> On Wed, Nov 18, 2015 at 1:16 PM, Cameron McKenzie <
>>> cammckenzie@apache.org> wrote:
>>>
>>>> Hey Vikrant,
>>>> The issue was that the LOST event was being published by Curator when
>>>> it gave up trying to reconnect to Zookeeper after connection loss, whereas
>>>> most people were interpreting it to mean that the session was lost.
>>>>
>>>> So, the change in CURATOR-3.0 is that the LOST event will be published
>>>> when the session has either expired and Curator is explicitly told this by
>>>> Zookeeper (implying that a connection is present), or when Curator has been
>>>> disconnected from Zookeeper for long enough for the session to have expired
>>>> on the server (this will occur when no connection to Zookeeper is present).
>>>>
>>>> So, I'm not sure how it will help your case. It is just a more reliable
>>>> way of knowing that the session is gone and all related ephemeral state on
>>>> the Zookeeper server will also be gone.
>>>>
>>>> Note that it's also possible to tell Curator to use the legacy way of
>>>> interpreting the LOST event.
>>>> cheers
>>>>
>>>>
>>>> On Thu, Nov 19, 2015 at 8:09 AM, Vikrant Singh <
>>>> vikrant.subscribe@gmail.com> wrote:
>>>>
>>>>> Hello All,
>>>>> I need some guidance on understanding how to a fix done in latest
>>>>> release 3.0.0 . I am talking about following fix -
>>>>> https://issues.apache.org/jira/browse/CURATOR-247 .
>>>>>
>>>>> In my project we create some ephemeral nodes and monitor a cluster
>>>>> through a tree cache . Framework for treecache and ephemeral node is
>>>>> created using ExponentialBackoffRetry with retry interval of 1 sec and
>>>>> retry count of 29 (which is MAX_RETRIES_LIMIT ) .  We do kill the
>>>>> process moment  we get TreeCacheEvent.Type.CONNECTION_LOST event .
>>>>>
>>>>> As process restart is really expensive, I want to understand how I can
>>>>> leverage from this fix.
>>>>>
>>>>> Please help me in understanding what is the issue and how it may
>>>>> affect a setup like ours. We are still not on 3.0.0.
>>>>>
>>>>> Thanks,
>>>>> Vikrant
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message