EdColeman commented on a change in pull request #2467:
URL: https://github.com/apache/accumulo/pull/2467#discussion_r801706468
##########
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 - both which can be long running operations, that
after they have been submitted, things could have changed such that they are
not longer desired - or at least not desired at that point in time.
It would also be desirable that a delete operation take precedence over any
other operation in progress or queued for a table. If a compaction or a bulk
import is running and then the system requests the table be deleted, the only
consistency required is that the metadata table remains correct and the proper
files get marked for gc'ing - anything else that is occurring is work that is
going to be thrown away. There is does not much benefit of having the
compaction continue to read / write data, that as soon as it completes is going
to be marked for deletion. There may be subtleties that I'm ignoring if the
table was cloned, but in practice, cloning seems to be rare,
--
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]
