[
https://issues.apache.org/jira/browse/HBASE-16208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373167#comment-15373167
]
Joseph commented on HBASE-16208:
--------------------------------
Because the server-name is unique to a given queue and because only the
original creator of a queue will add logs to a given queue (adding a log is how
you create a row for a queue in the Replication table), I think we don't have
to worry about this race condition between servers. Within a single server,
logs are only added during the preLogRoll and addSource(), and only removed
with removePeer(). But there is a safeguard (synchronizing on ReplicationPeers)
during removePeer() to prevent race conditions between removePeer() and
preLogRoll(). I think the behavior of calling addSource and removePeer on the
same peer at the same time is undefined and should be left up to the user to be
reasonable? What do you think [~eclark]? It would also be easy for me to run
the checkAndPut without aborting too though. I will put up a patch with that
version.
> Make TableBasedReplicationQueuesImpl check that queue exists before
> attempting to remove it
> -------------------------------------------------------------------------------------------
>
> Key: HBASE-16208
> URL: https://issues.apache.org/jira/browse/HBASE-16208
> Project: HBase
> Issue Type: Sub-task
> Components: Replication
> Reporter: Joseph
> Assignee: Joseph
> Attachments: HBASE-16208.patch
>
>
> Currently calling TableBasedReplicationQueuesImpl.removeQueue(String queueId)
> will cause it to delete the row with the given queue id. Yet this row is not
> created until the first log is registered for the queue. This causes the
> server to abort if we every try to remove a queue that has not had a log
> registered to it yet.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
