accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fuchs (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2219) parallelize the operation of certain FATE operations
Date Mon, 20 Jan 2014 15:46:20 GMT


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

View raw message