[
https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16027898#comment-16027898
]
ASF GitHub Bot commented on CURATOR-106:
----------------------------------------
Github user Randgalt commented on the issue:
https://github.com/apache/curator/pull/215
The watcher code is counting on starting the ZooKeeper operation from the
same thread as the Watcher. You're right the connection issues can get in the
way of this. But, to me, this is all moot. This is how Curator works today and
it would be very disruptive to change it now. We can't change deep behavior
like this without it affecting users of the library.
> 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)
