[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030018#comment-16030018
]
ASF GitHub Bot commented on CURATOR-106:
----------------------------------------
Github user srdo commented on the issue:
https://github.com/apache/curator/pull/215
@Randgalt I'm probably just going to leave this alone. The stack trace I
posted on the JIRA issue was from an application running 2.12.0. I've been
unable to provoke the stack overflow on 3.x. It still looks like it's possible
for the FailedDeleteManager to recurse a bunch through the same path as in the
stack trace, but since I can't provoke the error I'm not sure the bug still
exists. Since I can't test a potential fix I'd rather not change the code, at
least not unless someone encounters the error on 3.x.
> 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)
