[ACCUMULO-3832] Lots of spam on concurrent table deletions in the monitor

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Incomplete
• Component/s: master
• Assignee: Unassigned
• Reporter: Josh Elser
• Created: 19/May/15 18:32
• Updated: 03/Sep/21 22:15
• Resolved: 03/Sep/21 22:15

Description

We're all very used to seeing something like the following in the monitor when running randomwalk:

Failed to execute Repo, tid=4a9b2c5dea42ab5b
	java.lang.IllegalArgumentException: Table with id 10 does not exist
		at org.apache.accumulo.core.client.impl.Tables.getNamespaceId(Tables.java:239)
		at org.apache.accumulo.master.tableOps.DeleteTable.isReady(DeleteTable.java:38)
		at org.apache.accumulo.master.tableOps.DeleteTable.isReady(DeleteTable.java:26)
		at org.apache.accumulo.master.tableOps.TraceRepo.isReady(TraceRepo.java:47)
		at org.apache.accumulo.fate.Fate$TransactionRunner.run(Fate.java:69)
		at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
		at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
		at org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
		at java.lang.Thread.run(Thread.java:745)

We know that we can ignore it because it's just FATE doing the right thing – we wanted to delete a table, but it's already deleted, so there's nothing to do. Super.

The issue is that a less-experienced user might not realize that they can ignore this message. I think that in the DeleteTable FATE op, it would make sense to fail quietly when we try to delete something that is already gone. Yes, it is still deserving of an INFO or DEBUG message, but I don't think this should propagate up to the monitor.