[
https://issues.apache.org/jira/browse/CURATOR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15426964#comment-15426964
]
ASF GitHub Bot commented on CURATOR-344:
----------------------------------------
GitHub user gtully opened a pull request:
https://github.com/apache/curator/pull/161
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 https://github.com/gtully/curator CURATOR-344
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/curator/pull/161.patch
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 <[email protected]>
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: https://issues.apache.org/jira/browse/CURATOR-344
> 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 [0x00007f959d6d5000]
> java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at java.lang.Thread.sleep(Thread.java:340)
> at java.util.concurrent.TimeUnit.sleep(TimeUnit.java:360)
> at org.apache.curator.RetryLoop$1.sleepFor(RetryLoop.java:74)
> at
> org.apache.curator.retry.SleepingRetry.allowRetry(SleepingRetry.java:46)
> at org.apache.curator.retry.RetryNTimes.allowRetry(RetryNTimes.java:24)
> at org.apache.curator.RetryLoop.takeException(RetryLoop.java:188)
> at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:112)
> at
> org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:287)
> at
> org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
> at
> org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
> at
> org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:192)
> - locked <0x000000074326fb50> (a
> org.apache.curator.framework.recipes.shared.SharedValue)
> at
> org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:42)
> at
> org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:58)
> at
> org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)
> at
> org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505){code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
