ctubbsii commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r801719195
##########
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:
> Generally the two operations that would be useful to cancel would be
compactions and bulk-import
So, we currently have the ability to cancel compactions. I don't believe the
new bulk import is long-running. So, any problems with long-running bulk
imports should be alleviated by avoiding the old bulk import mechanism.
> It would also be desirable that a delete operation take precedence over
any other operation in progress or queued for a table.
Agreed, but I'm not sure that would require exposing anything to
users/admins. That should just be handled internally. I think recent work has
moved in this direction.
> There may be subtleties that I'm ignoring if the table was cloned
Cloning should be fast, but it may wait on other operations, like
compactions, just to avoid having to do its own redundant compactions. I'm not
sure. I'd have to check the code, but a sensible API for that might be to add
an option to wait for outstanding compactions (or to not wait).
--
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]
