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] [Closed] (CURATOR-187) ChildReaper does not respect built in leader election
Date Tue, 10 Feb 2015 03:47:34 GMT

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

Cameron McKenzie closed CURATOR-187.
------------------------------------
       Resolution: Fixed
    Fix Version/s: 2.7.2

> 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
>             Fix For: 2.7.2
>
>
> 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)

Mime
View raw message