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