accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Drob (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-3832) Lots of spam on concurrent table deletions in the monitor
Date Thu, 26 May 2016 16:27:13 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Drob updated ACCUMULO-3832:
--------------------------------
    Fix Version/s:     (was: 1.7.2)
                   1.7.3

> 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.7.3, 1.8.0
>
>
> 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)

Mime
View raw message