Thank you all for the comments, I got the point. Raised that issue because
in some of our tests we are using manual advance for the clock and that was
working just fine in 1.x releases (so create table operation was atomic
from this perspective). And that stops working with AMv2. Of course, we can
Stalling environmentedge as is done here does not work. In various areas in
internals we expect the clock to advance. This is not particular to AMv2.
As per Appy, we need HLC generally (it is almost there but needs some
concentrated effort to carry it the last few yards).
For AMv2, we have a
Yeah, you're right.
Unreliable clocks open a whole set of different issues which i didn't want
to go into for the question "the system capable to execute all that
transition stuff in less than 1 ms?". I thought that question was genuinely
asking how probable was the fabricated scenario i.e. if
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
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
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 {
