[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078715#comment-14078715
]
Cameron McKenzie edited comment on CURATOR-106 at 7/30/14 12:50 AM:
--------------------------------------------------------------------
I have had a look at this as well, and I don't think that it can recurse
because the client.delete().guaranteed().inBackground().forPath(path) call
shouldn't ever throw an exception because it's running in the background.
Perhaps instead of recursing in the case of an exception (which could only
happen due to some sort of bug), it should just log an error?
was (Author: cammckenzie):
I have had a look at this as well, and I don't think that it can recurse
because the client.delete().guaranteed().inBackground().forPath(path) call
shouldn't ever throw an exception because it's running in the background.
I think that this can be closed.
> 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.2#6252)
