Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-7051

CheckAndPut should properly read MVCC

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.95.2
    • Fix Version/s: 0.94.3, 0.95.0
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      See, for example:

      // TODO: Use MVCC to make this set of increments atomic to reads
      

      Here's an example of what I can happen (would probably be good to write up a test case for each read/update):
      Concurrent update via increment and put.

      The put grabs the row lock first and updates the memstore, but releases the row lock before the MVCC is advanced. Then, the increment grabs the row lock and reads right away, reading the old value and incrementing based on that.

      There are a few options here:
      1) Waiting for the MVCC to advance for read/updates: the downside is that you have to wait for updates on other rows.

      2) Have an MVCC per-row (table configuration): this avoids the unnecessary contention of 1)

      3) Transform the read/updates to write-only with rollup on read.. E.g. an increment would just have the number of values to increment.

      1. 7051.txt
        0.7 kB
        Lars Hofhansl

        Issue Links

          Activity

          Hide
          yuzhihong@gmail.com Ted Yu added a comment -

          be good to write up a test case for each read/update

          +1

          Looks like option #3 is better.

          Show
          yuzhihong@gmail.com Ted Yu added a comment - be good to write up a test case for each read/update +1 Looks like option #3 is better.
          Hide
          lhofhansl Lars Hofhansl added a comment - - edited

          Note that this is not as simple as it looks. Increments are not idempotent. They skirt the issue by making changes visible immediately so that other increments see the result of all previous increments.
          If that was not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically.
          That is why the memstoreTS is set to 0 for increments (making it visible immediately).

          Edit: Forgot an important "not" and spelling

          Show
          lhofhansl Lars Hofhansl added a comment - - edited Note that this is not as simple as it looks. Increments are not idempotent. They skirt the issue by making changes visible immediately so that other increments see the result of all previous increments. If that was not the case two increments of 1 with a base value of 0 could still just lead to 1, even when they are both applied atomically. That is why the memstoreTS is set to 0 for increments (making it visible immediately). Edit: Forgot an important "not" and spelling
          Hide
          gchanan Gregory Chanan added a comment -

          Hmm...interesting .

          The example in the description doesn't use two increments, though. Admittedly a weird case. But the same example should work with increment replaced with checkAndPut, which isn't as strange.

          Show
          gchanan Gregory Chanan added a comment - Hmm...interesting . The example in the description doesn't use two increments, though. Admittedly a weird case. But the same example should work with increment replaced with checkAndPut, which isn't as strange.
          Hide
          ram_krish ramkrishna.s.vasudevan added a comment -

          append() and incrment() also does not honour retries also. HBASE-6390 was raised for that but we did not proceed on that ?

          Show
          ram_krish ramkrishna.s.vasudevan added a comment - append() and incrment() also does not honour retries also. HBASE-6390 was raised for that but we did not proceed on that ?
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Actually checkAndPut is correct, no? I see no special logic that mucks with the memstoreTS or similar.

          The only really special operations are Increment and Append.

          @Ram: Since Increment and Append are not idempotent we cannot simply retry them (see discussion on HBASE-6390).

          Show
          lhofhansl Lars Hofhansl added a comment - Actually checkAndPut is correct, no? I see no special logic that mucks with the memstoreTS or similar. The only really special operations are Increment and Append. @Ram: Since Increment and Append are not idempotent we cannot simply retry them (see discussion on HBASE-6390 ).
          Hide
          gchanan Gregory Chanan added a comment -

          I think the special memstoreTS logic in Increment/Append is a separate issue than what I'm bringing up here. I could be wrong (I've just really started looking into this code). Could you explain what is wrong about the following:

          The current value of some cell is 10.
          I issue two concurrent requests:
          A) a check and put where check value = 10, put value = 11
          B) a put where put value = 50

          The only result at the end of these operations that seems reasonable to me is the value of the cell being 50. If A occurred first (ACID wise), then our values go 10->11->50. If B occurred first, then our values go 10->50 (and the checkAndPut fails). Or do we just not consider checkAndPuts to be transactions?

          My reading of the code is that we could get 11. B goes first but releases the rowLock before completing his MVCC memstore insert. Then A goes, reads 10 and puts 50.

          Show
          gchanan Gregory Chanan added a comment - I think the special memstoreTS logic in Increment/Append is a separate issue than what I'm bringing up here. I could be wrong (I've just really started looking into this code). Could you explain what is wrong about the following: The current value of some cell is 10. I issue two concurrent requests: A) a check and put where check value = 10, put value = 11 B) a put where put value = 50 The only result at the end of these operations that seems reasonable to me is the value of the cell being 50. If A occurred first (ACID wise), then our values go 10->11->50. If B occurred first, then our values go 10->50 (and the checkAndPut fails). Or do we just not consider checkAndPuts to be transactions? My reading of the code is that we could get 11. B goes first but releases the rowLock before completing his MVCC memstore insert. Then A goes, reads 10 and puts 50.
          Hide
          gchanan Gregory Chanan added a comment -

          Sorry last sentence should be:
          "Then A goes, reads 10 and puts 11"

          Show
          gchanan Gregory Chanan added a comment - Sorry last sentence should be: "Then A goes, reads 10 and puts 11"
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Yes. There is nothing special about checkAndPut.
          Maybe I am confused... What specifically do you want to fix w.r.t. checkAndPut?
          (I think the only weird things we have that do not honor MVCC are Increment and Append)

          Show
          lhofhansl Lars Hofhansl added a comment - Yes. There is nothing special about checkAndPut. Maybe I am confused... What specifically do you want to fix w.r.t. checkAndPut? (I think the only weird things we have that do not honor MVCC are Increment and Append)
          Hide
          gchanan Gregory Chanan added a comment -

          What does "Yes" refer to?

          I'm suggesting that the result of the above two operations should always be 50. Having the checkAndPut begin and complete a memstore insert before doing the read (option 1 above), is one example of how to get those semantics.

          Show
          gchanan Gregory Chanan added a comment - What does "Yes" refer to? I'm suggesting that the result of the above two operations should always be 50. Having the checkAndPut begin and complete a memstore insert before doing the read (option 1 above), is one example of how to get those semantics.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          "Yes" was agreeing that 50 should always be the outcome. Is that ever not the case?

          Show
          lhofhansl Lars Hofhansl added a comment - "Yes" was agreeing that 50 should always be the outcome. Is that ever not the case?
          Hide
          gchanan Gregory Chanan added a comment -

          Great. My surface-level reading of the code was that it could be 11, but I'll work on an actual test case .

          Show
          gchanan Gregory Chanan added a comment - Great. My surface-level reading of the code was that it could be 11, but I'll work on an actual test case .
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I don't see how that can happen. checkAndMutate takes a row lock, reads the row (following MVCC), and updates the row (which will also follow the MVCC protocol).

          Show
          lhofhansl Lars Hofhansl added a comment - I don't see how that can happen. checkAndMutate takes a row lock, reads the row (following MVCC), and updates the row (which will also follow the MVCC protocol).
          Hide
          ram_krish ramkrishna.s.vasudevan added a comment -

          Yes.. what Gregory says is possible.. i tried to reproduce this scenario that he mentioned. It happens..
          So if thread B is just before waiting for MVCC to complete and by the time of thread A does the check operation it is going to succeed.
          Now the MVCC completes and the put as part of checkAndPut gets completed thus overwriting what the thread B has written.

          Show
          ram_krish ramkrishna.s.vasudevan added a comment - Yes.. what Gregory says is possible.. i tried to reproduce this scenario that he mentioned. It happens.. So if thread B is just before waiting for MVCC to complete and by the time of thread A does the check operation it is going to succeed. Now the MVCC completes and the put as part of checkAndPut gets completed thus overwriting what the thread B has written.
          Hide
          ram_krish ramkrishna.s.vasudevan added a comment -

          Also this applies to other versions also right? Not only trunk?

          Show
          ram_krish ramkrishna.s.vasudevan added a comment - Also this applies to other versions also right? Not only trunk?
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I see. In HRegion.doMiniBatchPut we release the rowlock(s) before we roll the readPoint (completeMemstoreInsert). So for checkAndPut is not enough to hold the rowlock, since an earlier Put could have released the lock but not yet rolled readPoint... Is that what you guys are saying?

          I agree that is a problem and a side-effect of releasing the rowlock early to avoid holding it, while the WAL is sync'ed.

          Show
          lhofhansl Lars Hofhansl added a comment - I see. In HRegion.doMiniBatchPut we release the rowlock(s) before we roll the readPoint (completeMemstoreInsert). So for checkAndPut is not enough to hold the rowlock, since an earlier Put could have released the lock but not yet rolled readPoint... Is that what you guys are saying? I agree that is a problem and a side-effect of releasing the rowlock early to avoid holding it, while the WAL is sync'ed.
          Hide
          gchanan Gregory Chanan added a comment -

          Yes, that's what I'm saying Lars.

          What do you think about the options I give in the description? You mentioned holding the rowlock longer, which would also work, but (presumably) slow down all operations, not just checkAndPuts/increments/appends.

          Show
          gchanan Gregory Chanan added a comment - Yes, that's what I'm saying Lars. What do you think about the options I give in the description? You mentioned holding the rowlock longer, which would also work, but (presumably) slow down all operations, not just checkAndPuts/increments/appends.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Holding the rowlock longer would require us to hold the lock while we sync the WAL (because MVCC visibility must come after we sync the lock).
          The nuclear option would be to wait for all MVCC transactions to finish:

          MultiVersionConsistencyControl.WriteEntry w = mvcc.beginMemstoreInsert();
          mvcc.advanceMemstore(w);
          mvcc.waitForRead(w);
          

          This will wait for all prior transactions to finish. Even then there might be a race still.

          Show
          lhofhansl Lars Hofhansl added a comment - Holding the rowlock longer would require us to hold the lock while we sync the WAL (because MVCC visibility must come after we sync the lock). The nuclear option would be to wait for all MVCC transactions to finish: MultiVersionConsistencyControl.WriteEntry w = mvcc.beginMemstoreInsert(); mvcc.advanceMemstore(w); mvcc.waitForRead(w); This will wait for all prior transactions to finish. Even then there might be a race still.
          Hide
          gchanan Gregory Chanan added a comment -

          Lars: that's option 1. The downside is you have to wait for writes to complete on other rows, which is unnecessary. I don't think there is a race in there, but could be wrong.

          Option #2 is use an MVCC per row. Is that just infeasible? We could make it an option like "faster read/updates"

          Option #3 is make the read/updates write-only. That's probably more difficult.

          Show
          gchanan Gregory Chanan added a comment - Lars: that's option 1. The downside is you have to wait for writes to complete on other rows, which is unnecessary. I don't think there is a race in there, but could be wrong. Option #2 is use an MVCC per row. Is that just infeasible? We could make it an option like "faster read/updates" Option #3 is make the read/updates write-only. That's probably more difficult.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Can you explain #3 more.

          In the end this was really broken by the work to release the lock before the WAL is sync'ed (and since for that be correct MVCC need to be rolled forward after the WAL sync'ed, which means after the lock was released).

          Show
          lhofhansl Lars Hofhansl added a comment - Can you explain #3 more. In the end this was really broken by the work to release the lock before the WAL is sync'ed (and since for that be correct MVCC need to be rolled forward after the WAL sync'ed, which means after the lock was released).
          Hide
          ram_krish ramkrishna.s.vasudevan added a comment -

          @Gregory
          Option #3 can you pls explain more.
          Option #2-> what is the infeasibility you see? I have not thought on the soln for this anyway. If it is feasible i prefer #2.

          Show
          ram_krish ramkrishna.s.vasudevan added a comment - @Gregory Option #3 can you pls explain more. Option #2-> what is the infeasibility you see? I have not thought on the soln for this anyway. If it is feasible i prefer #2.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Thinking about this a bit more. Maybe the "nuclear" option isn't that nuclear after all.
          The internalPut or internalDelete of checkAndMutate will wait for all prior transactions to finish anyway. Now we just wait in the beginning, so we get only slightly less concurrency but correctness.

          I think the same will actually work for Increment and Append and we can get rid of the setting-the-memstoreTS-to-0 nonsense.

          Show
          lhofhansl Lars Hofhansl added a comment - Thinking about this a bit more. Maybe the "nuclear" option isn't that nuclear after all. The internalPut or internalDelete of checkAndMutate will wait for all prior transactions to finish anyway. Now we just wait in the beginning, so we get only slightly less concurrency but correctness. I think the same will actually work for Increment and Append and we can get rid of the setting-the-memstoreTS-to-0 nonsense.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Hit "Add" too early. Of course if the check condition is false, we get worse performance because now we waited for all previous transaction where in old code we wouldn't have.

          Show
          lhofhansl Lars Hofhansl added a comment - Hit "Add" too early. Of course if the check condition is false, we get worse performance because now we waited for all previous transaction where in old code we wouldn't have.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Also revived HBASE-4583.

          Show
          lhofhansl Lars Hofhansl added a comment - Also revived HBASE-4583 .
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Just posted a patch to HBASE-4583. We can do something similar here.
          Gregory, were you going to work on this? Otherwise I'll assign it to me.

          Show
          lhofhansl Lars Hofhansl added a comment - Just posted a patch to HBASE-4583 . We can do something similar here. Gregory, were you going to work on this? Otherwise I'll assign it to me.
          Hide
          gchanan Gregory Chanan added a comment -

          @Ram:
          regarding option 3: for an increment imagine you can just insert something into the memstore that says "increment by x". Since you don't have to read, you can just do what all the other writes do (i.e. don't wait for MVCC, just hold the row lock up to the sync point). Reads become more complicated, of course.

          Option 2:
          I was just thinking you would need to spend some memory per-row to hold the MVCC. Probably okay (similar to the row lock already?), but would need some investigation.

          @Lars:
          If you were to assign this to yourself, what approach would you take? Holding the row lock until the WAL is synced during writes? Waiting for all transactions to complete in read/updates?

          I'm down for trying out the #2 idea. We could benchmark it against the other approaches. Perhaps I should file a new JIRA for that?

          Show
          gchanan Gregory Chanan added a comment - @Ram: regarding option 3: for an increment imagine you can just insert something into the memstore that says "increment by x". Since you don't have to read, you can just do what all the other writes do (i.e. don't wait for MVCC, just hold the row lock up to the sync point). Reads become more complicated, of course. Option 2: I was just thinking you would need to spend some memory per-row to hold the MVCC. Probably okay (similar to the row lock already?), but would need some investigation. @Lars: If you were to assign this to yourself, what approach would you take? Holding the row lock until the WAL is synced during writes? Waiting for all transactions to complete in read/updates? I'm down for trying out the #2 idea. We could benchmark it against the other approaches. Perhaps I should file a new JIRA for that?
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I'd probably go with #1 honestly (as I said above it's not as nuclear as I had thought). I do not think #2 or #3 are worth the effort/risk.

          We always wait for all other transactions - in this region - to finish (that is true even for normal puts), this is a nice and simple design in HBase. Changing that to MVCC/row would also break the multi row transaction stuff I added (but that is only exposed through a coprocessor endpoint so breaking that would potentially be OK).

          MVCC is already per region, I do not think we should add a finer granularity here.

          Show
          lhofhansl Lars Hofhansl added a comment - I'd probably go with #1 honestly (as I said above it's not as nuclear as I had thought). I do not think #2 or #3 are worth the effort/risk. We always wait for all other transactions - in this region - to finish (that is true even for normal puts), this is a nice and simple design in HBase. Changing that to MVCC/row would also break the multi row transaction stuff I added (but that is only exposed through a coprocessor endpoint so breaking that would potentially be OK). MVCC is already per region, I do not think we should add a finer granularity here.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          BTW, the approach I took in HBASE-4583 is akin to #1.

          Show
          lhofhansl Lars Hofhansl added a comment - BTW, the approach I took in HBASE-4583 is akin to #1.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I would say this (checkAndXXX) is somewhat more critical than HBASE-4583 as it can actually lead to incorrect, permanent results.

          Show
          lhofhansl Lars Hofhansl added a comment - I would say this (checkAndXXX) is somewhat more critical than HBASE-4583 as it can actually lead to incorrect, permanent results.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Super simple patch. Just wait for prior MVCC transactions to finish, before we execute the Get.

          Show
          lhofhansl Lars Hofhansl added a comment - Super simple patch. Just wait for prior MVCC transactions to finish, before we execute the Get.
          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12551489/7051.txt
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

          -1 javadoc. The javadoc tool appears to have generated 85 warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          -1 findbugs. The patch appears to introduce 3 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests:
          org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit

          Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12551489/7051.txt against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 hadoop2.0 . The patch compiles against the hadoop 2.0 profile. -1 javadoc . The javadoc tool appears to have generated 85 warning messages. +1 javac . The applied patch does not increase the total number of javac compiler warnings. -1 findbugs . The patch appears to introduce 3 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests: org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3197//console This message is automatically generated.
          Hide
          gchanan Gregory Chanan added a comment -

          Patch looks good. Mind testing with Ram's test patch over in HBASE-7071? (I.e. that it fails w/o your patch, passes with).

          Show
          gchanan Gregory Chanan added a comment - Patch looks good. Mind testing with Ram's test patch over in HBASE-7071 ? (I.e. that it fails w/o your patch, passes with).
          Hide
          lhofhansl Lars Hofhansl added a comment -

          You mean HBASE-7077 I assume
          Yeah, will have a look.

          Show
          lhofhansl Lars Hofhansl added a comment - You mean HBASE-7077 I assume Yeah, will have a look.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Yep... Fails without this patch, but passes with it.
          This should go into 0.94 and 0.96.

          Show
          lhofhansl Lars Hofhansl added a comment - Yep... Fails without this patch, but passes with it. This should go into 0.94 and 0.96.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          OK... Lemme commit this, followed by HBASE-7071. Any objections?

          Show
          lhofhansl Lars Hofhansl added a comment - OK... Lemme commit this, followed by HBASE-7071 . Any objections?
          Hide
          gchanan Gregory Chanan added a comment -

          I'm +1 on this. I haven't looked at HBASE-7071 enough to +1 it. Want me to?

          Show
          gchanan Gregory Chanan added a comment - I'm +1 on this. I haven't looked at HBASE-7071 enough to +1 it. Want me to?
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Sigh... I also meant HBASE-7077. So this one + HBASE-7077.

          Show
          lhofhansl Lars Hofhansl added a comment - Sigh... I also meant HBASE-7077 . So this one + HBASE-7077 .
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Committed to 0.94 and 0.96.
          Thanks for bringing up the issue and Gregory and the review.

          Show
          lhofhansl Lars Hofhansl added a comment - Committed to 0.94 and 0.96. Thanks for bringing up the issue and Gregory and the review.
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94 #562 (See https://builds.apache.org/job/HBase-0.94/562/)
          HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94 #562 (See https://builds.apache.org/job/HBase-0.94/562/ ) HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-TRUNK #3503 (See https://builds.apache.org/job/HBase-TRUNK/3503/)
          HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404377)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
          Show
          hudson Hudson added a comment - Integrated in HBase-TRUNK #3503 (See https://builds.apache.org/job/HBase-TRUNK/3503/ ) HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404377) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/)
          HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #9 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/9/ ) HBASE-7051 CheckAndPut should properly read MVCC (Revision 1404379) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java

            People

            • Assignee:
              lhofhansl Lars Hofhansl
              Reporter:
              gchanan Gregory Chanan
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development