You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Josh Elser <jo...@gmail.com> on 2015/06/29 03:55:26 UTC
Excessive WARN'ing from FATE ops
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
Re: Excessive WARN'ing from FATE ops
Posted by Keith Turner <ke...@deenlo.com>.
On Sun, Jun 28, 2015 at 9:55 PM, Josh Elser <jo...@gmail.com> 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?
Yeah, there is no reason to warn about that.
>
>
> - Josh
>
Re: Excessive WARN'ing from FATE ops
Posted by Josh Elser <jo...@gmail.com>.
Thanks, Christopher and Keith!
I'll commit this later today.
Christopher wrote:
> Okay, I agree. Saw your patch which turns it to debug in these cases,
> and think that's a good solution.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, Jun 29, 2015 at 1:35 AM, Josh Elser<jo...@gmail.com> wrote:
>> 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<jo...@gmail.com> 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
Re: Excessive WARN'ing from FATE ops
Posted by Christopher <ct...@apache.org>.
Okay, I agree. Saw your patch which turns it to debug in these cases,
and think that's a good solution.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Jun 29, 2015 at 1:35 AM, Josh Elser <jo...@gmail.com> wrote:
> 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<jo...@gmail.com> 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
Re: Excessive WARN'ing from FATE ops
Posted by Josh Elser <jo...@gmail.com>.
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<jo...@gmail.com> 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
Re: Excessive WARN'ing from FATE ops
Posted by Christopher <ct...@apache.org>.
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 <jo...@gmail.com> 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