hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apekshit Sharma <a...@cloudera.com>
Subject Re: Assignment Manager and clock advance.
Date Wed, 03 Jan 2018 01:38:39 GMT
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 everything can
actually execute within 1ms realtime.

But talking about unreliable clocks, it's not just the problem of
non-incrementing, right? clock can go backwards also.
Sadly, our current EnvironmentEdgeManager isn't capable of handling such
cases and the HLC (HBASE-14070) effort to fix that hasn't seen much
progress lately :(
So yes, if clocks go bad, those bugs can happen even if operation is
spanning over seconds in realtime.

-- Appy


On Tue, Jan 2, 2018 at 5:01 PM, Nick Dimiduk <ndimiduk@gmail.com> wrote:

> 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 <appy@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 <
> sergeysoldatov@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
> >
>



-- 

-- Appy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message