[jira] [Created] (CURATOR-64) Retry logic appears to delay reconnect after session expiry

["Shaun Senecal (JIRA)" <ji...@apache.org>]

Shaun Senecal created CURATOR-64:
------------------------------------

             Summary: Retry logic appears to delay reconnect after session expiry
                 Key: CURATOR-64
                 URL: https://issues.apache.org/jira/browse/CURATOR-64
             Project: Apache Curator
          Issue Type: Bug
          Components: Framework
            Reporter: Shaun Senecal


If a watch is triggered immediately before a session expiry, and the watch attempts to fetch data from ZK (using Curator), its possible that the reconnect behaviour is delayed until the retry gives up

It currently looks something like this:

# watch A is triggered, begins processing
# session is expired (watch A hasnt completed execution yet)
# watch A attempts to fetch data from ZK (say: curator.getData()...)
# the getData() will retry until the policy tells it to give up (could be several minutes)
# finally curator will reconnect to ZK

I would expect something more like this:

# watch A is triggered, begins processing
# session is expired (watch A hasnt completed execution yet)
# watch A attempts to fetch data from ZK (say: curator.getData()...)
# the first getData() fails because of session expiry (should be nearly instantly)
# curator reconnects to ZK
# a second attempt to call getData() is made via the RetryPolicy
# watch A completes processing

We are using the BoundedExponentialBackoffRetry, so we end up waiting for quite a while after session expiry, leaving our services dead in the water for much longer than is necessary.


This occurs with curator v1.3.3 and ZK 3.4.5



--
This message was sent by Atlassian JIRA
(v6.1#6144)