[
https://issues.apache.org/jira/browse/ACCUMULO-4553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819149#comment-15819149
]
Christopher Tubbs commented on ACCUMULO-4553:
---------------------------------------------
Saw an issue that I think might be related to this earlier today. A colleague
reported to me that they saw a bunch of write locks disassociated from any fate
operation, while using the shell's fate command. When checking the logs, it
looks like these were write locks from lots of failed DeleteTable Repo
executions, and it doesn't look like any of these get cleaned up. I'm guessing
the colleague manually removes the transactions, but that leaves the locks
behind.
> DeleteTable repo not replayable
> -------------------------------
>
> Key: ACCUMULO-4553
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4553
> Project: Accumulo
> Issue Type: Bug
> Components: fate, master
> Affects Versions: 1.6.6, 1.7.2
> Reporter: John Vines
> Fix For: 1.7.3, 1.8.1, 2.0.0
>
>
> I had an issue where a table was stuck in a deleting state. I'm still digging
> into the specifics of the incident, but I'm looking at the DeleteTable repo
> and it does not seem safe to replay if the master goes down during execution.
> It calls TableManager.transitionTableState which does a zk mutation that does
> not allow Deleting->Deleting. This means that if the repo dies after the
> mutation but before seeding the next fate repo, any repeats will fail due to
> it already being in a deleting state.
> Furthermore, the only way to correct this behavior is to manually force the
> table into a non-deleting state via zk surgery, and no one wants that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
