curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-187) ChildReaper does not respect built in leader election
Date Mon, 09 Feb 2015 21:22:38 GMT

    [ 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 <dkesler@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 <dkesler@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 <dkesler@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)

Mime
View raw message