curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From srdo <>
Subject [GitHub] curator issue #215: CURATOR-106: Ensure background operations happen in the ...
Date Sat, 22 Apr 2017 17:08:26 GMT
Github user srdo commented on the issue:
    Hi @Randgalt. Just to make sure, you're talking about calls to BackgroundCallback.processResult,
    I don't follow how this change causes those to be invoked from a different thread than
usual. The changed code is only hit if processBackgroundOperation is called with a null event
(isInitialExecution is true). As far as I can tell, the invocations that happen from the Zookeeper
callbacks always seem to pass a non-null event, and so don't hit the changed code. 
    I took a look at the call sites for BackgroundCallback.processResult, and the only way
I can see that this change has changed the calling thread is if CuratorFrameworkImpl.processBackgroundOperation
is called with a null parameter, and CuratorFrameworkImpl.performBackgroundOperation then
hits a ConnectionLossException, through checkBackgroundRetry -> sendToBackgroundCallback
-> BackgroundCallback.processResult.
The other invocations of sendToBackgroundCallback (the only call site for BackgroundCallback.processResult
except for the wrapper in Backgrounding) only happen through a call to processBackgroundOperation
with a non-null event.
    I did a quick spot check using the BackgroundCallback in CuratorFrameworkBackground.testBasic.
Printing the thread executing BackgroundCallback.processResult before the change:
    The executing thread Thread[main-EventThread,5,main]
    after the change:
    The executing thread Thread[main-EventThread,5,main]

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message