A user will already get an error message via the Exception thrown by the
API. They don't need to look at the monitor to see an error message that
they must have already seen (unless the client is doing something dumb
like suppressing the error).
The error message sent to the client should be sufficient for the user
to understand why the command failed. I don't think we don't need to log
a warning on the server for a precondition/assertion failure.
Christopher wrote:
For the second error about namespace renaming... while that's pretty
annoying in RW, I'd be reluctant to drop the verbosity of it under
normal circumstances. Typically, renaming a table is going to be done
interactively, by a person... and there is a restriction that tables
cannot be "renamed" into a new namespace. It's probably pretty
important a user sees an error message about that, so they understand
why their attempt to rename failed. Do you have a better suggestion?
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Sun, Jun 28, 2015 at 9:55 PM, Josh Elser<[email protected]> wrote:
Noticed this while running randomwalk against 1.8.0-SNAPSHOT. The monitor's
aggregated log messages were just filled with things like the following:
Failed to execute Repo, tid=76367ba00e847e10
ThriftTableOperationException(tableId:null, tableName:ctt_000,
op:CREATE, type:EXISTS, description:null)
at
org.apache.accumulo.master.tableOps.Utils.checkTableDoesNotExist(Utils.java:54)
at
org.apache.accumulo.master.tableOps.PopulateZookeeper.call(PopulateZookeeper.java:54)
at
org.apache.accumulo.master.tableOps.PopulateZookeeper.call(PopulateZookeeper.java:30)
at
org.apache.accumulo.master.tableOps.TraceRepo.call(TraceRepo.java:57)
at
org.apache.accumulo.fate.Fate$TransactionRunner.run(Fate.java:72)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
at java.lang.Thread.run(Thread.java:745)
Now, this is happening because of the concurrent module renaming tests, but
is this really a warning that we want to propagate to the monitor?
Everything is just fine and dandy in the system. Doesn't seem like it really
needs to be a warning. Similarly, the following also falls into the same
bucket.
Cannot move tables to a new namespace by renaming. The namespace for
nspc_000.ctt_002 does not match ctt_001
Thoughts before I open an issue to change them?
- Josh
