curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Santiago M. Mola (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-106) Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
Date Wed, 21 Oct 2015 09:19:27 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966521#comment-14966521
] 

Santiago M. Mola commented on CURATOR-106:
------------------------------------------

I'm experiencing this bug, at least with older  versions of ZooKeeper. I hit it when using
InterProcessMutex#release(), which does a _foreground_ guaranteed delete. It seems that, with
guaranteed, a _foreground_ delete turns into a background guaranteed delete (which might also
lead to a race condition, but I still have to test that case). At some point, the recursion
is triggered and stack overflow is thrown.

I will send a pull request to make FailedDeleteManager#addFailedDelete use a while loop instead
of recursion and solve the stack overflow. But there are probably more critical problems to
solve here (e.g. race conditions).


> 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.4#6332)

Mime
View raw message