curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-344) SharedValue watcher should limit work to valid data change events
Date Sun, 28 Aug 2016 23:07:21 GMT

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

Mime
View raw message