[
https://issues.apache.org/jira/browse/ACCUMULO-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14292138#comment-14292138
]
Jonathan Park commented on ACCUMULO-3530:
-----------------------------------------
[~ctubbsii] Is there a particular case you're concerned with?
I'm not too familiar with the fate locks but the general problem we observed
was that while a clone was in progress, a table had an iterator configuration
removed. The clone operation ended up failing because the ZK node correlated w/
the iterator config disappeared. I believe the ask here is that while an
iterative read + copy of the table properties is in progress, changes should be
disallowed so that a consistent read of the set of table properties is copied.
> alterTable/NamespaceProperty should use Fate locks
> --------------------------------------------------
>
> Key: ACCUMULO-3530
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3530
> Project: Accumulo
> Issue Type: Bug
> Reporter: John Vines
>
> Fate operations, such as clone table, have logic in place to ensure
> consistency as the operation occurs. However, operaitons like
> alterTableProperty can still interfere because there is no locking done. We
> should add identical locking to these methods in MasterClientServiceHandler
> to help ensure consistency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
