I don't think these assumptions are reliable. I've seen cases where subsequent calls to currentTimeMillis() are non-incrementing on specific Linux distributions. Taken in aggregate, the system clock makes progress, but those aggregations are on the multi-second scale.
On Tue, Jan 2, 2018 at 4:37 PM Apekshit Sharma <a...@cloudera.com> wrote: > Hi Sergey, > > Interesting test and find. Makes total sense too. > However, in real world case, any put in meta table itself will take more > than a ms, and then we have lot of Procedure framework and other logic in > between meta accesses which would make this scenarios impossible. > Specifically, there a lot of processing in between adding rows from > CreateTableProcedure and trying to access it in children > AssignProcedure(s). > > -- Apy > > On Tue, Jan 2, 2018 at 3:58 PM, Sergey Soldatov <sergeysolda...@gmail.com> > wrote: > > > Hi, > > Not sure whether we may consider that as a bug, but I found an > interesting > > dependency of AM2 on clock advancing. A simple operation such as create > > table is unable to perform with the same current_time value: > > > > public void testCreateTable() throws IOException { > > EnvironmentEdgeManager.injectEdge(new EnvironmentEdge() { > > volatile int curTime = 1000; > > > > @Override > > public long currentTime() { > > > > return curTime; > > } > > }); > > final TableName tableName = TableName.valueOf("test"); > > TEST_UTIL.createTable(tableName, HConstants.CATALOG_FAMILY).close(); > > } > > > > and fails with a TableNotFound exception. The reason is that between > > transitions we get table information from meta using Get with the > exclusive > > current timestamp. Could it be a potential problem (i.e. the system > capable > > to execute all that transition stuff in less than 1 ms)? > > > > Thanks, > > Sergey > > > > > > -- > > -- Appy >