[
https://issues.apache.org/jira/browse/ACCUMULO-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14292365#comment-14292365
]
Christopher Tubbs commented on ACCUMULO-3530:
---------------------------------------------
That's fine, but it doesn't explain how that's expected to solve the
consistency problem. The consistency problem is hard, because ZK configs can
propagate at different times in different servers, and we don't know how to
instruct servers to expire their cache.
Unless... are you proposing that the fate operation itself propagate
instructions to expire every tserver's cache of the property being changed?
> 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)
