[ 
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)

Reply via email to