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
>
