accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Park (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3530) alterTable/NamespaceProperty should use Fate locks
Date Mon, 26 Jan 2015 17:41:34 GMT


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:
>             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

View raw message