[
https://issues.apache.org/jira/browse/ACCUMULO-4398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs resolved ACCUMULO-4398.
-----------------------------------------
Resolution: Won't Fix
This is another case of the more general situation where one server in the
network has not yet seen a ZooKeeper change that the client knows about. In
this specific situation, though, we can get around it because we now (in 2.0)
supports creating split points at table creation time.
If this still requires action to mitigate further, we can re-open this on
https://github.com/apache/accumulo/issues
> Possible for client to see TableNotFoundException adding splits on a newly
> created table
> ----------------------------------------------------------------------------------------
>
> Key: ACCUMULO-4398
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4398
> Project: Accumulo
> Issue Type: Bug
> Components: client, zookeeper
> Affects Versions: 1.7.1
> Reporter: Josh Elser
> Priority: Major
>
> Just came across a really odd scenario. I believe that it's a race condition
> in the client that stems from our beloved {{ZooCache}}.
> This was observed via a test failure in {{LogicalTimeIT}}:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 29.249 sec
> <<< FAILURE! - in org.apache.accumulo.test.functional.LogicalTimeIT
> run(org.apache.accumulo.test.functional.LogicalTimeIT) Time elapsed: 29.037
> sec <<< ERROR!
> org.apache.accumulo.core.client.TableNotFoundException: Table
> LogicalTimeIT_run06 does not exist
> at
> org.apache.accumulo.core.client.impl.Tables._getTableId(Tables.java:117)
> at
> org.apache.accumulo.core.client.impl.Tables.getTableId(Tables.java:102)
> at
> org.apache.accumulo.core.client.impl.TableOperationsImpl.addSplits(TableOperationsImpl.java:374)
> at
> org.apache.accumulo.test.functional.LogicalTimeIT.runMergeTest(LogicalTimeIT.java:81)
> at
> org.apache.accumulo.test.functional.LogicalTimeIT.run(LogicalTimeIT.java:56)
> {noformat}
> Ultimately:
> {code}
> conn.tableOperations().create(table, new
> NewTableConfiguration().setTimeType(TimeType.LOGICAL));
> TreeSet<Text> splitSet = new TreeSet<Text>();
> for (String split : splits) {
> splitSet.add(new Text(split));
> }
> conn.tableOperations().addSplits(table, splitSet);
> {code}
> The important piece to remember is that a ZooKeeper client, when a watcher is
> set, will eventually get all updates from that watcher in the order which
> they occurred. LogicalTimeIT is repeatedly running the same test over tables
> of varying characteristics. I think these are the important points.
> Consider the following:
> # Client creates a table T1
> # ZooCache is cleared after FATE op finishes
> # Watcher is set on ZTABLES in ZK
> # Client interacts with T1
> # Client creates T2
> # ZooCache is cleared after FATE op finishes
> # Watcher fires on ZTABLES node in ZK (CHILDREN_CHANGED) and repopulates the
> child list on the ZTABLES node
> # Client makes call to split T2
> # Code will check if the table exists, but the childrenCache will be
> repopulated in ZooCache which will cause the client to think the table
> doesn't exit
> # Eventually, the watcher would fire and ZTABLES would be updated and
> everything is fine.
> I believe this is a plausible scenario, however perhaps unlikely.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
