You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Jordan Zimmerman (JIRA)" <ji...@apache.org> on 2015/02/10 02:49:34 UTC

[jira] [Updated] (CURATOR-187) ChildReaper does not respect built in leader election

     [ https://issues.apache.org/jira/browse/CURATOR-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jordan Zimmerman updated CURATOR-187:
-------------------------------------
    Assignee: Cameron McKenzie  (was: Jordan Zimmerman)

> ChildReaper does not respect built in leader election
> -----------------------------------------------------
>
>                 Key: CURATOR-187
>                 URL: https://issues.apache.org/jira/browse/CURATOR-187
>             Project: Apache Curator
>          Issue Type: Bug
>            Reporter: David Kesler
>            Assignee: Cameron McKenzie
>
> ChildReaper has built in leader election, but ChildReaper itself doesn't actually respect it.  It merely passes it along to the Reaper.  This means that the child reaper will continue to watch its path and add nodes that need to be reaped into the reaper's queue, despite the reaper (potentially) not being active.
> This has two negative effects:
> 1) It creates a memory leak as the child reaper will continuously add paths to the reaper's list of activePaths without the reaper having any mechanism for removing them from its list.
> 2) It creates a backlog of paths so that if the reaper ever does become leader it needs to churn through all the nodes that have been added to its queue since it started (or lost leadership).  In a high enough volume scenario, this can result in a substantial delay before the reaper begins successfully processing paths that still exist and need to be reaped.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)