[
https://issues.apache.org/jira/browse/ACCUMULO-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13875234#comment-13875234
]
Keith Turner commented on ACCUMULO-2219:
----------------------------------------
Fate operations are executed in a thread pool. The size in configurable by
setting master.fate.threadpool.size, it defaults to 4. Operations that do not
lock the same table should be able to execute in parallel. If an operation
tries to lock a table that already locked, it should yield and not tie up the
fate thread. When you say things are backed up, do you know more about what
was going on? Did you happen to look the output of the fate admin print
command? It shows what operations have locks and are waiting to get locks.
> 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)
