curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CURATOR-344) SharedValue watcher should limit work to valid data change events
Date Thu, 18 Aug 2016 18:40:20 GMT


ASF GitHub Bot commented on CURATOR-344:

GitHub user gtully opened a pull request:

    CURATOR-344 - limit shared value watcher to valid change events to av…

    …oid work on disconnect.
    Test that shows the difficulty with blocking the event thread. 
    When the framework is shared and one use case needs timely notification of suspend, a
use case that requires retry for some period gets in the way.
    In any event, on a disconnect, there may or may not be change, it does not make sense
to me that the listeners should be fired.

You can merge this pull request into a Git repository by running:

    $ git pull CURATOR-344

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #161
commit f89ddfafb45c4656ea34474f061ca902c7060116
Author: gtully <>
Date:   2016-08-18T18:34:10Z

    CURATOR-344 - limit shared value watcher to valid change events to avoid work on disconnect


> SharedValue watcher should limit work to valid data change events 
> ------------------------------------------------------------------
>                 Key: CURATOR-344
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 3.2.0
>            Reporter: Gary Tully
> With a RetryNTimes retry policy and a disconnect. The event thread can get blocked on
retries from the SharedValue watcher readValue, blocking other listeners from getting the
SUSPENDED event till retry completes.
> Seems the watcher should limit work and notifications to valid change events and ignore
a disconnect. The ConnectionStateListener already handles those.
> Same thread stack that blocks other listeners.
> {code}main-EventThread" daemon prio=10 tid=0x00007f95d009f000 nid=0x3429 waiting on condition
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
> 	at java.lang.Thread.sleep(Native Method)
> 	at java.lang.Thread.sleep(
> 	at java.util.concurrent.TimeUnit.sleep(
> 	at org.apache.curator.RetryLoop$1.sleepFor(
> 	at org.apache.curator.retry.SleepingRetry.allowRetry(
> 	at org.apache.curator.retry.RetryNTimes.allowRetry(
> 	at org.apache.curator.RetryLoop.takeException(
> 	at org.apache.curator.RetryLoop.callWithRetry(
> 	at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(
> 	at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(
> 	at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(
> 	at
> 	- locked <0x000000074326fb50> (a
> 	at$100(
> 	at$1.process(
> 	at org.apache.curator.framework.imps.NamespaceWatcher.process(
> 	at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(
> 	at org.apache.zookeeper.ClientCnxn${code}

This message was sent by Atlassian JIRA

View raw message