[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980031#comment-15980031
]
ASF GitHub Bot commented on CURATOR-106:
----------------------------------------
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]
> Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
> ---------------------------------------------------------------------------
>
> Key: CURATOR-106
> URL: https://issues.apache.org/jira/browse/CURATOR-106
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 2.4.2
> Reporter: Jasdeep Hundal
> Fix For: awaiting-response
>
>
> For guaranteed deletes (eg. lock releases) that fail, the FailedDeleteManager
> issues another guaranteed delete here:
> https://github.com/apache/curator/blob/master/curator-framework/src/main/java/org/apache/curator/framework/imps/FailedDeleteManager.java#L35
> In an environment where ZK has the potential to be down for an extended
> period of time, this has the potential to recurse until there is a stack
> overflow (particularly if the application is using multiple locks.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
