accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-4699) Map in SequentialWorkAssigner uses two different keys
Date Fri, 01 Sep 2017 16:53:00 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16150820#comment-16150820
] 

Michael Miller commented on ACCUMULO-4699:
------------------------------------------

>From [~elserj]:
This part of the code is meant to handle the case when the active master changes while there
data out to be replicated. The Master should initialize itself with the current state of ZooKeeper
to know what has already been assigned out for replication (by the previous active Master).
I can see that this bug would result in the Master holding onto some memory that it would
never free (in the Map), and it would result in the Master trying to submit it back out to
the cluster. However, I think eventually the Master (or TabletServer which took the work task)
would see that there is no more work to be done and eventually clean up the record.
I believe, by nature of the DistributedWorkQueue, there is sufficient exclusion to prevent
two TabletServers from concurrently trying to replicate the same WAL. However, I believe the
worst case would be that we inadvertently replicate the entire WAL twice.

> Map in SequentialWorkAssigner uses two different keys
> -----------------------------------------------------
>
>                 Key: ACCUMULO-4699
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4699
>             Project: Accumulo
>          Issue Type: Bug
>          Components: replication
>    Affects Versions: 1.7.3, 1.8.1
>            Reporter: Michael Miller
>            Assignee: Josh Elser
>             Fix For: 1.7.4, 1.8.2, 2.0.0
>
>
> SequentialWorkAssigner has a map used for tracking replication work called queuedWorkByPeerName
which it quite clearly uses peerName as the key.  There is a line of code in the initializeQueuedWork()
method which does a put on the queuedWorkByPeerName map but uses tableId as the key.
> This is a simple code fix but I created a ticket here as it could have further implications
on the replication process.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message