[
https://issues.apache.org/jira/browse/CURATOR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15437138#comment-15437138
]
ASF GitHub Bot commented on CURATOR-344:
----------------------------------------
Github user gtully commented on the issue:
https://github.com/apache/curator/pull/161
Thanks for taking the time to peek at this. I agree.
Doing everything async will make it a little heaver weight but I think it
is more correct.
There seems to be be some recipes that take executors, others that don't,
but I have not figured out if there is some pattern to this. Do you know?
Short term, I can fix up the unit test to be deterministic (i.e. wait for
connected).
Maybe this can be tackled in two phases. The first making the watcher more
discriminating. For my use case, disconnecting is the important event.
> 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.
> Sample 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)
