[jira] [Commented] (ACCUMULO-2219) parallelize the operation of certain FATE operations

["Keith Turner (JIRA)" <ji...@apache.org>]

    [ 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)