[
https://issues.apache.org/jira/browse/CURATOR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15444282#comment-15444282
]
ASF GitHub Bot commented on CURATOR-344:
----------------------------------------
Github user cammckenzie commented on the issue:
https://github.com/apache/curator/pull/161
I'm not sure on the pattern for executors, probably just the whim of
whoever implemented the recipe I imagine.
I think that you should be able to do this asynchronously without an
executor though. If you change the readValue() method to have an option of
executing in the background then it should fix the problem I think. When being
called from the Watcher, you would make the readValue getData() call in the
background and update the shared value in the asynchronous callback.
That should fix the problem properly and not require the introduction of an
executor. I think that we should clean up the events which actually result in
the readValue() being called from the Watcher too.
> 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)