[
https://issues.apache.org/jira/browse/ACCUMULO-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16552251#comment-16552251
]
Ed Coleman commented on ACCUMULO-3806:
--------------------------------------
I'm not sure that I agree with this - I see that this has existed as an issue
for a while, but I not sure modifying
{color:#000000}/src/main/java/org/apache/accumulo/master/tableOps/Utils.java{color}
is necessarily the best way to handle an issue seen during random walk
testing.
What about a production system? If I have an existing table and try to create a
"new" table, I think I rather have it fail with the exception that the table
exists so that I am forced to handle it. With the exception, I can catch it
and either proceed with the existing table, or fail so that I do not corrupt
existing data with whatever I was going to next. If it just logs a message, it
seems that I could be proceeding when I would not want to.
I need to look further into where this is occurring in random-walk test, maybe
we should improve the table naming so that it is not "common", or we could
defeat the message in the test, or it could be handled by modifying the logging
configuration.
Thanks for looking at this.
> Failing to create a table/namespace because it already exists should not be a
> warning
> -------------------------------------------------------------------------------------
>
> Key: ACCUMULO-3806
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3806
> Project: Accumulo
> Issue Type: Improvement
> Components: fate
> Reporter: Josh Elser
> Priority: Major
> Labels: newbie
> Fix For: 2.0.0
>
> Attachments:
> 0001-ACCUMULO-3806-changed-checkTableDoesNotExist-in-accu.patch
>
>
> This is a really common occurrence when you're running randomwalk:
> {noformat}
> Failed to execute Repo, tid=63d0421f1b17b04a
> ThriftTableOperationException(tableId:null, tableName:nspc_001.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: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}
> Concurrent table creations run: only one succeeds and the others fail. This
> is expected and what FATE was designed to handle. We shouldn't be pushing
> these up to the monitor -- should probably be a info or debug message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
