[
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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)
