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 <[email protected]> > Yes, go ahead. > > On Sep 2, 2013, at 4:17 AM, Michael Morello <[email protected]> > 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
