Josh Elser created ACCUMULO-3832:
------------------------------------
Summary: Lots of spam on concurrent table deletions in the monitor
Key: ACCUMULO-3832
URL: https://issues.apache.org/jira/browse/ACCUMULO-3832
Project: Accumulo
Issue Type: Improvement
Components: master
Reporter: Josh Elser
Priority: Minor
Fix For: 1.8.0, 1.7.1
We're all very used to seeing something like the following in the monitor when
running randomwalk:
{noformat}
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)
{noformat}
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
