dlmarion commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r801868052
##########
File path:
shell/src/main/java/org/apache/accumulo/shell/commands/FateCommand.java
##########
@@ -136,7 +140,29 @@ public int execute(final String fullCommand, final
CommandLine cl, final Shell s
getZooReaderWriter(context, siteConfig,
cl.getOptionValue(secretOption.getOpt()));
ZooStore<FateCommand> zs = new ZooStore<>(path, zk);
- if ("fail".equals(cmd)) {
+ if ("fail-live".equals(cmd)) {
Review comment:
Feedback from user(s) is:
1. cancelling a compaction from the compact command has never worked.
> Is it broken in 1.x versions?
2. Stopping the Manager is a problem because they can't load data via bulk
imports, they have strict timeliness requirements. They have to stop bulk
imports from getting kicked off, wait for the current ones to finish, then take
down the Manager. Stopping the Manager also stops any long-running WAL recovery
due to a failed TServer, table balancing, etc.
3. Another case is issuing DeleteRows command to remove some data that is
causing problems system-wide. The DeleteRows operation may be blocked by less
important Fate transactions which may be operating on a different range within
the table.
4. Accumulo's approach to locking the entire table seems heavy-handed.
There could be bulk imports and compactions running that affect one active part
of a table (let's say a newer date) and we're trying to deleterows or merge on
a completely different range that's inactive (older dates).
> Maybe we should support Row or Range locks?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
