curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cameron McKenzie (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CURATOR-106) Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
Date Wed, 30 Jul 2014 00:50:38 GMT

    [ 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)

Mime
View raw message