Github user srdo commented on the issue:
https://github.com/apache/curator/pull/215
Hi @Randgalt. Just to make sure, you're talking about calls to
BackgroundCallback.processResult, right?
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.
https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/CuratorFrameworkImpl.java#L857.
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 [email protected] or file a JIRA ticket
with INFRA.
---
