hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-610) Autoincrementing cell version
Date Wed, 30 Apr 2008 22:45:55 GMT

    [ https://issues.apache.org/jira/browse/HBASE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593455#action_12593455
] 

stack commented on HBASE-610:
-----------------------------

Regards my scenario above, I don't think its possible.  Upon review, regionservers update
using no explicit timestamp.  Means that their edits get applied using the current time of
the regionserver hosting the region taking on the edits, not that of the regionserver who
is in the past.  HBASE-609's problem was that master was asking to open scanner on a .META.
region using an explicit time, the current time on the master... not current time on hosting
regionserver.

> Autoincrementing cell version
> -----------------------------
>
>                 Key: HBASE-610
>                 URL: https://issues.apache.org/jira/browse/HBASE-610
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: stack
>             Fix For: 0.2.0
>
>
> HBASE-609 has an example of clock skew making it so master scanner missed edits placed
there by a regionserver whose clock was in advance of the masters.  There may be other cases
lurking where this kind of issue -- two servers are updating a particular row with off-clocks
-- may bite us.  Could a regionserver that has a clock a long ways behind the running master's
clock enter a split record that went in behind the current inforegion cell's version?  If
so, the master wouldn't see the split.
> One fix would be a new feature where cells had a version that autoincremented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message