You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/02/09 22:22:38 UTC
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14312906#comment-14312906 ]
ASF GitHub Bot commented on CURATOR-187:
----------------------------------------
GitHub user dkesler opened a pull request:
https://github.com/apache/curator/pull/66
Curator 187
A fix for the problem described in https://issues.apache.org/jira/browse/CURATOR-187. The ChildReaper continuously runs even when its Reaper is not the leader, resulting in a pileup of paths to reap in the Reaper's queue.
This changeset allows the ChildReaper to create the LeaderLatch so that it too can avoid doing any work (i.e. adding paths to the Reaper's queue) if this application is not the leader.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/yodle/curator CURATOR-187
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/curator/pull/66.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #66
----
commit 520ae54ac4a49292201417fa6b1104cf579704d3
Author: David Kesler <dk...@yodle.com>
Date: 2015-02-09T18:19:20Z
Adding a new constructor to Reaper so that it can optionally take a fully constructed leader latch that is owned by another class rather than create its own leader latch
commit 9da79604bfe7e775d1d42a25f0ac7579b8ee0464
Author: David Kesler <dk...@yodle.com>
Date: 2015-02-09T18:25:51Z
Reaper now sets its initial reapingIsActive state based on the state of the leader latch in case the leader latch was already started before being passed into the reaper's constructor
commit 49eb02a04f377a3b9e2da3b3904311ddddf1aa9d
Author: David Kesler <dk...@yodle.com>
Date: 2015-02-09T18:50:39Z
ChildReaper now creates a leaderLatch itself if a leader path is provided and does no work (such as passing paths to its Reaper) if it is not currently the leader.
----
> 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: Jordan Zimmerman
>
> 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)