hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jiraposter@reviews.apache.org (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4507) Create checkAndPut variant that exposes timestamp / UUID
Date Fri, 30 Sep 2011 06:03:48 GMT

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

jiraposter@reviews.apache.org commented on HBASE-4507:

bq.  On 2011-09-29 22:18:31, Ted Yu wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java, line 1948
bq.  > <https://reviews.apache.org/r/2118/diff/1/?file=46471#file46471line1948>
bq.  >
bq.  >     Since expectedTimestampOfLatestVersion would only be used for use case from
HBASE04497, I think we just need a reliable way of enforcing this 1 ms advance.
bq.  >     Maybe spinlocking till EnvironmentEdgeManager.currentTimeMillis() returns now+1
bq.  Jonathan Gray wrote:
bq.      Why do we need to wait until currentTimeMillis() rolls?
bq.      This is pretty ugly but I think we'll need to do something for HBASE-4497 and this
will work (as I'm understanding it).
bq.      But if we didn't do the +1, wouldn't the only time this would be an issue be if RS1
was hosting R1, it then got unassigned and reassigned BACK to RS1 again, and RS1 updates META
with the new location of R1 in the same millisecond that it did the original update to META
the last time it opened R1.  That seems overwhelmingly impossible :)  I'd be okay without
the +1 business, but at the least, let's make sure it's documented in the top-level API javadoc
(i think it is)

I'm thinking that we should never need it but in case we do......

Two regionservers would have to be trying to update meta at the same time AND somehow the
host that was carrying .META. had its clock go backwards -- e.g. .META. moved to a server
whose clock was behind -- and then the update of location by one of the regionservers would
have to arrive at EXACTLY the millisecond the original edit had AND the update that is going
in would have to be the same value as is already there.

I think its impossible but Ming postulated it so for peace of mind, we'll make sure every
edit IF the value being updated has same coordinates for sure has its on timestamp... we'll
+1 it if they happen to land in same millisecond (Yes its up in the javadoc that each edit
has for sure unique timestamp).

Ted, you +1 or you have a better idea for the +1'ing (The +1'ing has a unit test!)

- Michael

This is an automatically generated e-mail. To reply, visit:

On 2011-09-29 23:52:43, Michael Stack wrote:
bq.  -----------------------------------------------------------
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/2118/
bq.  -----------------------------------------------------------
bq.  (Updated 2011-09-29 23:52:43)
bq.  Review request for hbase.
bq.  Summary
bq.  -------
bq.  Adds a checkAndPut that takes a timestamp
bq.  This addresses bug hbase-4507.
bq.      https://issues.apache.org/jira/browse/hbase-4507
bq.  Diffs
bq.  -----
bq.    src/main/java/org/apache/hadoop/hbase/ipc/HRegionInterface.java 3679c02 
bq.    src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 6ec857c 
bq.    src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 96b763b 
bq.    src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java 99b34cc 
bq.  Diff: https://reviews.apache.org/r/2118/diff
bq.  Testing
bq.  -------
bq.  Thanks,
bq.  Michael

> Create checkAndPut variant that exposes timestamp / UUID
> --------------------------------------------------------
>                 Key: HBASE-4507
>                 URL: https://issues.apache.org/jira/browse/HBASE-4507
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Ted Yu
>            Assignee: stack
> Michael checked the checkAndPut which doesn't expose timestamp. A variant of checkAndPut
should be created to expose timestamp which is written into a column specified by additional

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message