You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Michael Morello <mi...@gmail.com> on 2013/09/02 13:17:08 UTC
Callbacks are not called on retry-able errors
I have noticed that retry-able errors (CONNECTIONLOSS, OPERATIONTIMEOUT,
SESSIONMOVED, SESSIONEXPIRED) are not propagated to callback when the retry
policy gave up if the operation is done in background.
It is a little bit confusing because it is not the behavior of the
Zookeeper client.
Check the 2 test cases here : https://gist.github.com/barkbay/6411061
Would you mind if i open a JIRA with the following patch :
https://github.com/barkbay/incubator-curator/commit/c58d4d8e76ee12137092d95c1ef33d4fa85e5aea#curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java
Re: Callbacks are not called on retry-able errors
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I responded on the Jira. But, the TL;DR of it is that there is a major hole in background processing. The initial (or re-acquire of the) ZooKeeper connection is not being retried for background operations. I've plugged this hole in branch CURATOR-52. I'd appreciate a code review from any/all.
-JZ
On Sep 10, 2013, at 6:29 AM, Michael Morello <mi...@gmail.com> wrote:
> Unfortunately i'm still having "connection loss" events that are not
> propagated to callbacks.
>
> It happens when Curator call ConnectionState.checkTimeouts, if the
> connection has been lost for Math.min(sessionTimeoutMs,
> connectionTimeoutMs) then a ConnectionLoss exception is raised even if the
> session has not actually expired (because the session timeout is far less
> than connection timeout).
> Here is a unit test : https://gist.github.com/barkbay/6507997
>
> The bad news is that since it is an exception (and not a "legacy" Zookeeper
> event) it is handled by
> CuratorFrameworkImpl.handleBackgroundOperationException that does not
> propagate the event to the callback.
>
> A workaround might be to add this kind of thing :
> https://gist.github.com/barkbay/6507963
> What are your thoughts on that?
>
> 2013/9/2 Jordan Zimmerman <jo...@jordanzimmerman.com>
>
>> Yes, go ahead.
>>
>> On Sep 2, 2013, at 4:17 AM, Michael Morello <mi...@gmail.com>
>> wrote:
>>
>>> I have noticed that retry-able errors (CONNECTIONLOSS, OPERATIONTIMEOUT,
>>> SESSIONMOVED, SESSIONEXPIRED) are not propagated to callback when the
>> retry
>>> policy gave up if the operation is done in background.
>>>
>>> It is a little bit confusing because it is not the behavior of the
>>> Zookeeper client.
>>> Check the 2 test cases here : https://gist.github.com/barkbay/6411061
>>>
>>> Would you mind if i open a JIRA with the following patch :
>>>
>> https://github.com/barkbay/incubator-curator/commit/c58d4d8e76ee12137092d95c1ef33d4fa85e5aea#curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java
>>
>>
>
>
> --
> Michael
> https://github.com/barkbay/
> https://twitter.com/barkbay
Re: Callbacks are not called on retry-able errors
Posted by Michael Morello <mi...@gmail.com>.
Unfortunately i'm still having "connection loss" events that are not
propagated to callbacks.
It happens when Curator call ConnectionState.checkTimeouts, if the
connection has been lost for Math.min(sessionTimeoutMs,
connectionTimeoutMs) then a ConnectionLoss exception is raised even if the
session has not actually expired (because the session timeout is far less
than connection timeout).
Here is a unit test : https://gist.github.com/barkbay/6507997
The bad news is that since it is an exception (and not a "legacy" Zookeeper
event) it is handled by
CuratorFrameworkImpl.handleBackgroundOperationException that does not
propagate the event to the callback.
A workaround might be to add this kind of thing :
https://gist.github.com/barkbay/6507963
What are your thoughts on that?
2013/9/2 Jordan Zimmerman <jo...@jordanzimmerman.com>
> Yes, go ahead.
>
> On Sep 2, 2013, at 4:17 AM, Michael Morello <mi...@gmail.com>
> wrote:
>
> > I have noticed that retry-able errors (CONNECTIONLOSS, OPERATIONTIMEOUT,
> > SESSIONMOVED, SESSIONEXPIRED) are not propagated to callback when the
> retry
> > policy gave up if the operation is done in background.
> >
> > It is a little bit confusing because it is not the behavior of the
> > Zookeeper client.
> > Check the 2 test cases here : https://gist.github.com/barkbay/6411061
> >
> > Would you mind if i open a JIRA with the following patch :
> >
> https://github.com/barkbay/incubator-curator/commit/c58d4d8e76ee12137092d95c1ef33d4fa85e5aea#curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java
>
>
--
Michael
https://github.com/barkbay/
https://twitter.com/barkbay
Re: Callbacks are not called on retry-able errors
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Yes, go ahead.
On Sep 2, 2013, at 4:17 AM, Michael Morello <mi...@gmail.com> wrote:
> I have noticed that retry-able errors (CONNECTIONLOSS, OPERATIONTIMEOUT,
> SESSIONMOVED, SESSIONEXPIRED) are not propagated to callback when the retry
> policy gave up if the operation is done in background.
>
> It is a little bit confusing because it is not the behavior of the
> Zookeeper client.
> Check the 2 test cases here : https://gist.github.com/barkbay/6411061
>
> Would you mind if i open a JIRA with the following patch :
> https://github.com/barkbay/incubator-curator/commit/c58d4d8e76ee12137092d95c1ef33d4fa85e5aea#curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java