[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027869#comment-16027869
]
ASF GitHub Bot commented on CURATOR-106:
----------------------------------------
Github user srdo commented on the issue:
https://github.com/apache/curator/pull/215
@Randgalt Could you elaborate on why this is wrong? If I understand you,
the issue is that background callbacks must happen in the Zookeeper thread, not
CuratorFrameworkImpl's ExecutorService thread? I still don't see how this is
changed by the code you posted. In order for there to be a change in behavior,
a Zookeeper thread must call `CuratorFrameworkImpl.processBackgroundOperation`
with a null event. If the event is not null, the behavior is unchanged.
I'm having a hard time finding any instances of
`CuratorFrameworkImpl.processBackgroundOperation` being called with a null
event from a Zookeeper callback. The calls I can find all have a non-null event
when called from inside a Zookeeper callback.
It looks to me like all the calls to `processBackgroundOperation` with a
null event are coming from `forPath` or equivalent (e.g. `forOperations`).
Aren't those running in the user's thread, and not one of Zookeeper's threads?
Do you have an example where the thread executing the background callback
has changed, or any calls to `processBackgroundOperation` with a null event
from Zookeeper callback code?
> 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)
