curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CURATOR-106) Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
Date Sun, 28 May 2017 17:23:04 GMT


ASF GitHub Bot commented on CURATOR-106:

Github user srdo commented on the issue:
    @Randgalt Could you elaborate on why this is wrong? If I understand you, the issue is
that background callbacks must happen in the Zookeeper thread, not CuratorFrameworkImpl's
ExecutorService thread? I still don't see how this is changed by the code you posted. In order
for there to be a change in behavior, a Zookeeper thread must call `CuratorFrameworkImpl.processBackgroundOperation`
with a null event. If the event is not null, the behavior is unchanged.
    I'm having a hard time finding any instances of `CuratorFrameworkImpl.processBackgroundOperation`
being called with a null event from a Zookeeper callback. The calls I can find all have a
non-null event when called from inside a Zookeeper callback.
    It looks to me like all the calls to `processBackgroundOperation` with a null event are
coming from `forPath` or equivalent (e.g. `forOperations`). Aren't those running in the user's
thread, and not one of Zookeeper's threads?
    Do you have an example where the thread executing the background callback has changed,
or any calls to `processBackgroundOperation` with a null event from Zookeeper callback code?

> Issuing a guaranteed delete can cause stack overflow if ZK is not reachable
> ---------------------------------------------------------------------------
>                 Key: CURATOR-106
>                 URL:
>             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:
> 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

View raw message