[
https://issues.apache.org/jira/browse/ACCUMULO-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876528#comment-13876528
]
Adam Fuchs commented on ACCUMULO-2219:
--------------------------------------
The case that I saw was when the first operation was a table deletion (that was
stuck due to minor compaction failure), and the second operation was a range
deletion of a different table. I didn't analyze the locking using fate admin
print, but I did notice that the second operation was blocked. Any idea which
lock they would have been contending for, or do I need to try to replicate this?
> parallelize the operation of certain FATE operations
> ----------------------------------------------------
>
> Key: ACCUMULO-2219
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2219
> Project: Accumulo
> Issue Type: Improvement
> Components: fate
> Affects Versions: 1.4.4, 1.5.0
> Reporter: Adam Fuchs
>
> As in ACCUMULO-2217, a user operation can cause the FATE processor to get
> stuck and require administrative action to make progress on any future FATE
> operations. We should look at ways to parallelize the execution of FATE tasks
> that commute and don't interfere with each other. Maybe there are some rules
> we can use to run certain well-known operations in parallel (like a merge on
> one table at the same time as a deletion of another table, for example).
> This has a strong impact on multi-tenancy, preventing one user's operations
> from hosing all the other users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
