HBase
  1. HBase
  2. HBASE-5997

Fix concerns raised in HBASE-5922 related to HalfStoreFileReader

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.90.6, 0.92.1, 0.94.0, 0.95.2
    • Fix Version/s: 0.94.2
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      1. 5997v3_trunk.txt
        4 kB
        stack
      2. 5997v3_trunk.txt
        4 kB
        stack
      3. 5997v3_trunk.txt
        4 kB
        stack
      4. 5997v3_trunk.txt
        4 kB
        stack
      5. HBASE-5997_0.94.patch
        2 kB
        Anoop Sam John
      6. HBASE-5997_94 V2.patch
        4 kB
        Anoop Sam John
      7. HBASE-5997_94 V3.patch
        4 kB
        Anoop Sam John
      8. Testcase.patch.txt
        5 kB
        Anoop Sam John

        Issue Links

          Activity

          Hide
          Anoop Sam John added a comment -

          Well this problem is not that straight forward as the other one
          Ya obviously we need <= 0 check in the top file if check

          if (top) {
                    if (getComparator().compare(key, offset, length, splitkey, 0,
                        splitkey.length) < 0) {
                      return false;
                    }
                  } 
          

          But the problem is to the comparator we pass the splitkey which will be rowkey only and the other key is the KV key. This KV key can contain other bytes than the rowkey bytes. So in this when the rowkey = splitkey , still the comparator will give a value >0...

          I am checking the usage of the seekBefore and what is the key which will come to here..

          Show
          Anoop Sam John added a comment - Well this problem is not that straight forward as the other one Ya obviously we need <= 0 check in the top file if check if (top) { if (getComparator().compare(key, offset, length, splitkey, 0, splitkey.length) < 0) { return false ; } } But the problem is to the comparator we pass the splitkey which will be rowkey only and the other key is the KV key. This KV key can contain other bytes than the rowkey bytes. So in this when the rowkey = splitkey , still the comparator will give a value >0... I am checking the usage of the seekBefore and what is the key which will come to here..
          Hide
          Anoop Sam John added a comment -

          Was able to produce one issue
          Have one table with a region [r1-r5). Now split this region with splitkey as r3
          The two regions will be [r1-r3) and [r3-r5)
          Now call HTable.getRowOrBefore() with passing row as r3 (splitkey)
          Mean while there is no data with rowkey as r3 in the table

          The above call will create a seekBefore on the top half file with key as r3 and currently it will seek into the bottom file and gets the last KV in that file.

          After getting the KV in the HRegion.getClosestRowBefore(), there is a Get call to fetch the KV. This Get will fail in 1st step itself as the rowkey it is trying to fetch is not in range of [r3,r5).. So in my scenario the call is throwing Exception
          WrongRegionException("Requested row out of range for......")

          Show
          Anoop Sam John added a comment - Was able to produce one issue Have one table with a region [r1-r5). Now split this region with splitkey as r3 The two regions will be [r1-r3) and [r3-r5) Now call HTable.getRowOrBefore() with passing row as r3 (splitkey) Mean while there is no data with rowkey as r3 in the table The above call will create a seekBefore on the top half file with key as r3 and currently it will seek into the bottom file and gets the last KV in that file. After getting the KV in the HRegion.getClosestRowBefore(), there is a Get call to fetch the KV. This Get will fail in 1st step itself as the rowkey it is trying to fetch is not in range of [r3,r5).. So in my scenario the call is throwing Exception WrongRegionException("Requested row out of range for......")
          Hide
          Anoop Sam John added a comment -

          As I mentioned there are 2 issues
          1. We need to change the if check such that return false when the passed key is equal to the splitkey also. Because in the file there wont be any KV with rowkey less than the splitkey. That will be obviously in the bottom half.
          2. In the comparator we pass the passed key as the left item and the split key byte[] as the right item. The split key always byte[] will contains
          rowkeylenth + rowkey. There wont be any bytes corresponding to CF name or qualifier name or the timestamp bytes. So when the passed key is with rowkey=splitkey and contains any bytes corresponding to any of these items ( well this is key of KV and contain any ) the comparator will return a value >0

          Calls getting to this API from HBase code pass only rowkey(rowkeylenth + rowkey) and a timestamp [timestamp=HConstants.LATEST_TIMESTAMP] But no CF name and qualifier name. So if the top file contains KVs with rowkey as splitkey still all those KVs will look as greater than the passed key as every KV will contain the CF name bytes after the rowkey bytes. So always it will seek into the bottom half.

          Can we take only the part of the byte[] passed to this method ( seekBefore)? We need to take only the bytes rowkeylenth + rowkey
          like below

          -          if (getComparator().compare(key, offset, length, splitkey, 0,
          -              splitkey.length) < 0) {
          +          short lrowlength = Bytes.toShort(key, offset);
          +          if (getComparator().compare(key, offset, lrowlength, splitkey, 0,
          +              splitkey.length) <= 0) {
          
          Show
          Anoop Sam John added a comment - As I mentioned there are 2 issues 1. We need to change the if check such that return false when the passed key is equal to the splitkey also. Because in the file there wont be any KV with rowkey less than the splitkey. That will be obviously in the bottom half. 2. In the comparator we pass the passed key as the left item and the split key byte[] as the right item. The split key always byte[] will contains rowkeylenth + rowkey. There wont be any bytes corresponding to CF name or qualifier name or the timestamp bytes. So when the passed key is with rowkey=splitkey and contains any bytes corresponding to any of these items ( well this is key of KV and contain any ) the comparator will return a value >0 Calls getting to this API from HBase code pass only rowkey(rowkeylenth + rowkey) and a timestamp [timestamp=HConstants.LATEST_TIMESTAMP] But no CF name and qualifier name. So if the top file contains KVs with rowkey as splitkey still all those KVs will look as greater than the passed key as every KV will contain the CF name bytes after the rowkey bytes. So always it will seek into the bottom half. Can we take only the part of the byte[] passed to this method ( seekBefore)? We need to take only the bytes rowkeylenth + rowkey like below - if (getComparator().compare(key, offset, length, splitkey, 0, - splitkey.length) < 0) { + short lrowlength = Bytes.toShort(key, offset); + if (getComparator().compare(key, offset, lrowlength, splitkey, 0, + splitkey.length) <= 0) {
          Hide
          Ted Yu added a comment -

          @Anoop:
          Good analysis.
          Can you put the scenario described @ 17/May/12 10:09 into a test ?
          Then it is easier to validate your proposal above.

          Show
          Ted Yu added a comment - @Anoop: Good analysis. Can you put the scenario described @ 17/May/12 10:09 into a test ? Then it is easier to validate your proposal above.
          Hide
          Anoop Sam John added a comment -

          Includes the test case which reproduces the issue which I was mentioning..seekBefore() on top half file seeks into the bottom half.

          I am getting the below exception

          org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=1, exceptions:
          Fri May 18 00:44:07 IST 2012, org.apache.hadoop.hbase.client.HTable$4@619130e2, org.apache.hadoop.hbase.regionserver.WrongRegionException: org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range for Get on HRegion t1,r3,1337282045838.51accaef959568917250932a1863f4fe., startKey='r3', getEndKey()='', row='r2'
          
          	at org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:183)
          	at org.apache.hadoop.hbase.client.HTable.getRowOrBefore(HTable.java:644)
          	at org.apache.hadoop.hbase.io.TestHBASE5997.testHalfScannerSeekBefore(TestHBASE5997.java:93)
          
          Show
          Anoop Sam John added a comment - Includes the test case which reproduces the issue which I was mentioning..seekBefore() on top half file seeks into the bottom half. I am getting the below exception org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=1, exceptions: Fri May 18 00:44:07 IST 2012, org.apache.hadoop.hbase.client.HTable$4@619130e2, org.apache.hadoop.hbase.regionserver.WrongRegionException: org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range for Get on HRegion t1,r3,1337282045838.51accaef959568917250932a1863f4fe., startKey='r3', getEndKey()='', row='r2' at org.apache.hadoop.hbase.client.ServerCallable.withRetries(ServerCallable.java:183) at org.apache.hadoop.hbase.client.HTable.getRowOrBefore(HTable.java:644) at org.apache.hadoop.hbase.io.TestHBASE5997.testHalfScannerSeekBefore(TestHBASE5997.java:93)
          Hide
          Anoop Sam John added a comment -

          the table.getRowOrBefore("r3".getBytes(), FAMILY); will reach the region [r3,) and so to the half store file but will seek and into bottom..

          Show
          Anoop Sam John added a comment - the table.getRowOrBefore("r3".getBytes(), FAMILY); will reach the region [r3,) and so to the half store file but will seek and into bottom..
          Hide
          stack added a comment -

          @Anoop Excellent work.

          Show
          stack added a comment - @Anoop Excellent work.
          Hide
          Anoop Sam John added a comment -

          Actually there is another issue with the HTable.getRowOrBefore() API I think... Not with this half store file reading..

          Show
          Anoop Sam John added a comment - Actually there is another issue with the HTable.getRowOrBefore() API I think... Not with this half store file reading..
          Hide
          Anoop Sam John added a comment -

          Sorry could not complete the typing and by mistake pressed submit
          Continuation of the above comment
          As per the documentation of this API

           * Return the row that matches <i>row</i> exactly,
             * or the one that immediately precedes it.
          

          If there are 2 regions in a table [r1,r3) and [r3,r5)
          When this API is called with row as r3, The client will select the second region. And suppose there is no KV in this region with rowkey as r3. So the return from this region will be null... But still as a user I would expect the call to return highest row from the 1st region. Say there we have row with key r2...

          Still this API will not do that and will return null

          This same kind of handling might be needed when we have more than one region in the META table also...

          Hope I am making it clear

          Show
          Anoop Sam John added a comment - Sorry could not complete the typing and by mistake pressed submit Continuation of the above comment As per the documentation of this API * Return the row that matches <i>row</i> exactly, * or the one that immediately precedes it. If there are 2 regions in a table [r1,r3) and [r3,r5) When this API is called with row as r3, The client will select the second region. And suppose there is no KV in this region with rowkey as r3. So the return from this region will be null... But still as a user I would expect the call to return highest row from the 1st region. Say there we have row with key r2... Still this API will not do that and will return null This same kind of handling might be needed when we have more than one region in the META table also... Hope I am making it clear
          Hide
          Anoop Sam John added a comment -

          Whatever issue I was mentioning above, we can make out of this JIRA. So will focus on the HalfStoreFileReader issue here.. Will deal the other with another JIRA issue.

          Show
          Anoop Sam John added a comment - Whatever issue I was mentioning above, we can make out of this JIRA. So will focus on the HalfStoreFileReader issue here.. Will deal the other with another JIRA issue.
          Hide
          Anoop Sam John added a comment -

          Patch for 0.94 version

          Now I have changed like the check will compare the rowkey only. From the external usage of this API within HBase code, we always do the seekBefore based on rowkey only. Not with rowkey+cf+qualifier way.

          Pls provide your suggestion

          Once the solution is ok I can backport for other versions.

          Show
          Anoop Sam John added a comment - Patch for 0.94 version Now I have changed like the check will compare the rowkey only. From the external usage of this API within HBase code, we always do the seekBefore based on rowkey only. Not with rowkey+cf+qualifier way. Pls provide your suggestion Once the solution is ok I can backport for other versions.
          Hide
          Ted Yu added a comment -

          @Anoop:
          Is your patch supposed to fix the problem shown in the unit test published yesterday ?
          With the patch, I still see the following test failure:

          testHalfScannerSeekBefore(org.apache.hadoop.hbase.io.TestHBASE5997)  Time elapsed: 3.193 sec  <<< ERROR!
          org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=1, exceptions:
          Fri May 18 10:31:13 PDT 2012, org.apache.hadoop.hbase.client.HTable$4@605df3c5, org.apache.hadoop.hbase.regionserver.WrongRegionException: org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range for Get on HRegion t1,r3,1337362272730.9f3ae0ff1963c95df2df0aa768e739fc., startKey='r3', getEndKey()='', row='r2'
          
          Show
          Ted Yu added a comment - @Anoop: Is your patch supposed to fix the problem shown in the unit test published yesterday ? With the patch, I still see the following test failure: testHalfScannerSeekBefore(org.apache.hadoop.hbase.io.TestHBASE5997) Time elapsed: 3.193 sec <<< ERROR! org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=1, exceptions: Fri May 18 10:31:13 PDT 2012, org.apache.hadoop.hbase.client.HTable$4@605df3c5, org.apache.hadoop.hbase.regionserver.WrongRegionException: org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range for Get on HRegion t1,r3,1337362272730.9f3ae0ff1963c95df2df0aa768e739fc., startKey='r3', getEndKey()='', row='r2'
          Hide
          Anoop Sam John added a comment -

          The patch was addressing the issue with that API alone.
          Sorry I could not run that E2E test case. I was out of work for some days.
          I have looked into the E2E flow of the getRowOrBefore() in case of ref files being present for the regions.. Seems some other issues also... Will work on this and come up with the analysis and patch soon.

          Show
          Anoop Sam John added a comment - The patch was addressing the issue with that API alone. Sorry I could not run that E2E test case. I was out of work for some days. I have looked into the E2E flow of the getRowOrBefore() in case of ref files being present for the regions.. Seems some other issues also... Will work on this and come up with the analysis and patch soon.
          Hide
          Anoop Sam John added a comment -

          I have gone through the flow for this API. I think there are some issues

          1. In Store.rowAtOrBeforeFromStoreFile()
          Gets StoreFile.Reader.getFirstKey()
          In case of the half store file, this reader just calls the actual file reader. But this will give the 1st key in the physical HFile(which is the 1st key in the bottom half file also). The getFirstKey() is not overriden in the HalfStoreFileReader.

          2. In Store.rowAtOrBeforeFromStoreFile() itself
          HFileScanner scanner = r.getHFileReader().getScanner(true, true, false);
          In case of the half file, r will be the HalfStoreFileReader instance. But as we dont call getScanner() on "r", always it will get the actual HFileScanner for the HFile( The delegator in the HFileScanner instance in HalfStoreFileReader ).

          3. Other than these 2 issues we need to correct the issue with the seekBefore() API in the HalfStoreFileReader.getScanner

          I will address these issues and give a patch in some time.

          Show
          Anoop Sam John added a comment - I have gone through the flow for this API. I think there are some issues 1. In Store.rowAtOrBeforeFromStoreFile() Gets StoreFile.Reader.getFirstKey() In case of the half store file, this reader just calls the actual file reader. But this will give the 1st key in the physical HFile(which is the 1st key in the bottom half file also). The getFirstKey() is not overriden in the HalfStoreFileReader. 2. In Store.rowAtOrBeforeFromStoreFile() itself HFileScanner scanner = r.getHFileReader().getScanner(true, true, false); In case of the half file, r will be the HalfStoreFileReader instance. But as we dont call getScanner() on "r", always it will get the actual HFileScanner for the HFile( The delegator in the HFileScanner instance in HalfStoreFileReader ). 3. Other than these 2 issues we need to correct the issue with the seekBefore() API in the HalfStoreFileReader.getScanner I will address these issues and give a patch in some time.
          Hide
          Anoop Sam John added a comment -

          Patch addressing the issues I mentioned above. The attached test case wont throw Exception now. But this return null.. This issue I already commented above. We will try to address the same in another JIRA.
          [The API will only work with one region, if no apt data found there it will just return null to the user. But IMO it should go its previous region and get the data]

          Show
          Anoop Sam John added a comment - Patch addressing the issues I mentioned above. The attached test case wont throw Exception now. But this return null.. This issue I already commented above. We will try to address the same in another JIRA. [The API will only work with one region, if no apt data found there it will just return null to the user. But IMO it should go its previous region and get the data]
          Hide
          Anoop Sam John added a comment -

          @Stack, @Ted Can u people have a look at the patch pls?

          Show
          Anoop Sam John added a comment - @Stack, @Ted Can u people have a look at the patch pls?
          Hide
          ramkrishna.s.vasudevan added a comment -

          @Stack
          Can have a look at this?May be needed in the RCs that we will be taking either for 0.94 or 0.92.

          Show
          ramkrishna.s.vasudevan added a comment - @Stack Can have a look at this?May be needed in the RCs that we will be taking either for 0.94 or 0.92.
          Hide
          stack added a comment -

          @Anoop Great work. Agree on the seekBefore finding. Lets fix that in another issue.

          On the patch, minor comment only (I'm good w/ commit):

              if (firstKey == null) {
          

          Is it possible if the file is empty say that we'll seek on every invocation of getFirstKey?

          This patch does not do you your compare of row only rather than compare of full key. Is it supposed to?

          Show
          stack added a comment - @Anoop Great work. Agree on the seekBefore finding. Lets fix that in another issue. On the patch, minor comment only (I'm good w/ commit): if (firstKey == null ) { Is it possible if the file is empty say that we'll seek on every invocation of getFirstKey? This patch does not do you your compare of row only rather than compare of full key. Is it supposed to?
          Hide
          Lars Hofhansl added a comment -

          BTW. HTableInterface.getRowOrBefore is deprecated. Nobody should be using that.
          Are the issues you address here seen during our particular internal meta lookups (which are special cases)?

          (It's time to fix HBASE-2600)

          Show
          Lars Hofhansl added a comment - BTW. HTableInterface.getRowOrBefore is deprecated. Nobody should be using that. Are the issues you address here seen during our particular internal meta lookups (which are special cases)? (It's time to fix HBASE-2600 )
          Hide
          Anoop Sam John added a comment -

          Are the issues you address here seen during our particular internal meta lookups (which are special cases)?

          No. META table will have only one region which will not get split.(As of now)

          This issue was raised as a followup for HBASE-5922. This was reported as real use case issue. That issue was with bottom half store.

          Show
          Anoop Sam John added a comment - Are the issues you address here seen during our particular internal meta lookups (which are special cases)? No. META table will have only one region which will not get split.(As of now) This issue was raised as a followup for HBASE-5922 . This was reported as real use case issue. That issue was with bottom half store.
          Hide
          Lars Hofhansl added a comment -

          Ah yes, so we can move this to 0.94.2 then, I think. Agreed?

          Show
          Lars Hofhansl added a comment - Ah yes, so we can move this to 0.94.2 then, I think. Agreed?
          Hide
          stack added a comment -

          @Lars I think you should commit it just because of the amount of sweat Anoop expended here. Those two findings of his are pretty cool, pretty fancy detective work (The call is deprecated but still pivotal right until we do the replacement?). Just an opinion. Yeah, could go to 0.94.2.

          Show
          stack added a comment - @Lars I think you should commit it just because of the amount of sweat Anoop expended here. Those two findings of his are pretty cool, pretty fancy detective work (The call is deprecated but still pivotal right until we do the replacement?). Just an opinion. Yeah, could go to 0.94.2.
          Hide
          Lars Hofhansl added a comment -

          @Stack: Completely agree. I'm good on committing.
          @Anoop: Can you briefly address Stack's questions above? After that I'll check it in. Thanks for all the work on this!

          Show
          Lars Hofhansl added a comment - @Stack: Completely agree. I'm good on committing. @Anoop: Can you briefly address Stack's questions above? After that I'll check it in. Thanks for all the work on this!
          Hide
          ramkrishna.s.vasudevan added a comment -

          +1 on committing. Thanks to Anoop for the nice finding.
          Thanks Stack and Lars.

          Show
          ramkrishna.s.vasudevan added a comment - +1 on committing. Thanks to Anoop for the nice finding. Thanks Stack and Lars.
          Hide
          Anoop Sam John added a comment -

          @Lars
          I am okey for 94.2
          Yes I will address Stacks comments. [Was bit busy with some other works:(]
          @Stack
          Thanks a lot for your review.

          Show
          Anoop Sam John added a comment - @Lars I am okey for 94.2 Yes I will address Stacks comments. [Was bit busy with some other works:(] @Stack Thanks a lot for your review.
          Hide
          Lars Hofhansl added a comment -

          Heh, Stack and I were saying it's fine for 0.94.1

          Show
          Lars Hofhansl added a comment - Heh, Stack and I were saying it's fine for 0.94.1
          Hide
          Anoop Sam John added a comment -

          Is it possible if the file is empty say that we'll seek on every invocation of getFirstKey?

          Yes as the check is against firstKey being not null. May be we can have a boolean variable based check.
          As this is rare chance and the existance of the half file also wont be for more time( normally) I thought may be okey. What do u say Stack? If you feel I can change this.

          This patch does not do you your compare of row only rather than compare of full key. Is it supposed to?

          Yes. You can see that the comparison now is against the first key in the file rather than the split key

          -          if (getComparator().compare(key, offset, length, splitkey, 0,
          -              splitkey.length) < 0) {
          +          byte[] fk = getFirstKey();
          +          // This will be null when the file is empty in which we can not seekBefore to any key
          +          if (fk == null) return false;
          +          if (getComparator().compare(key, offset, length, fk, 0,
          +              fk.length) <= 0) {
          

          So it is okey to have the full key based compare.[Not rowkey alone]

          Show
          Anoop Sam John added a comment - Is it possible if the file is empty say that we'll seek on every invocation of getFirstKey? Yes as the check is against firstKey being not null. May be we can have a boolean variable based check. As this is rare chance and the existance of the half file also wont be for more time( normally) I thought may be okey. What do u say Stack? If you feel I can change this. This patch does not do you your compare of row only rather than compare of full key. Is it supposed to? Yes. You can see that the comparison now is against the first key in the file rather than the split key - if (getComparator().compare(key, offset, length, splitkey, 0, - splitkey.length) < 0) { + byte [] fk = getFirstKey(); + // This will be null when the file is empty in which we can not seekBefore to any key + if (fk == null ) return false ; + if (getComparator().compare(key, offset, length, fk, 0, + fk.length) <= 0) { So it is okey to have the full key based compare. [Not rowkey alone]
          Hide
          stack added a comment -

          On the first item, won't that be a seek each time we go for the firstKey in an empty file? It will be rare yes, but could be a pain if happened so would suggest a boolean flag for whether or not we've done the first key check.

          On the second item when we do the compare, are the offsets to where the key bytes start or to where the key starts (with its length preample)? For sure, we are comparing the row portions of keys?

          Thanks Anoop.

          (@Lars Maybe its ok putting this into 0.94.2 or into second 0.94.1RC).

          Show
          stack added a comment - On the first item, won't that be a seek each time we go for the firstKey in an empty file? It will be rare yes, but could be a pain if happened so would suggest a boolean flag for whether or not we've done the first key check. On the second item when we do the compare, are the offsets to where the key bytes start or to where the key starts (with its length preample)? For sure, we are comparing the row portions of keys? Thanks Anoop. (@Lars Maybe its ok putting this into 0.94.2 or into second 0.94.1RC).
          Hide
          Anoop Sam John added a comment -

          On the second item when we do the compare, are the offsets to where the key bytes start or to where the key starts (with its length preample)? For sure, we are comparing the row portions of keys?

          Offset will be to the key(with its length preample). KeyComparator will be used.we can see how the rowLength being considered. We compare the full key (rowKey and then CF, qualifier... )

          Show
          Anoop Sam John added a comment - On the second item when we do the compare, are the offsets to where the key bytes start or to where the key starts (with its length preample)? For sure, we are comparing the row portions of keys? Offset will be to the key(with its length preample). KeyComparator will be used.we can see how the rowLength being considered. We compare the full key (rowKey and then CF, qualifier... )
          Hide
          Anoop Sam John added a comment -

          Patch addressing Stack's comment

          Show
          Anoop Sam John added a comment - Patch addressing Stack's comment
          Hide
          Lars Hofhansl added a comment -

          @Stack: Are you OK with latest patch? Could put this in 0.94.2 and 0.96.

          Show
          Lars Hofhansl added a comment - @Stack: Are you OK with latest patch? Could put this in 0.94.2 and 0.96.
          Hide
          stack added a comment -

          +1 on commit to trunk. Anoop worked hard at this (sorry we ignored it so long Anoop). Patch looks good to me. Up to you if you want to risk 0.94.2. It does make us more 'correct' so, I'd say yeah, go for it.

          Show
          stack added a comment - +1 on commit to trunk. Anoop worked hard at this (sorry we ignored it so long Anoop). Patch looks good to me. Up to you if you want to risk 0.94.2. It does make us more 'correct' so, I'd say yeah, go for it.
          Hide
          Lars Hofhansl added a comment -

          v3 looks good to me +1

          Show
          Lars Hofhansl added a comment - v3 looks good to me +1
          Hide
          Lars Hofhansl added a comment -

          Is this only against 0.94 (i.e. fixed in 0.96 already)?
          The attached patches are all against 0.94.

          Show
          Lars Hofhansl added a comment - Is this only against 0.94 (i.e. fixed in 0.96 already)? The attached patches are all against 0.94.
          Hide
          stack added a comment -

          Version for trunk (Same just that the diff for Store needs to be against HStore in trunk – it was renamed).

          Show
          stack added a comment - Version for trunk (Same just that the diff for Store needs to be against HStore in trunk – it was renamed).
          Hide
          stack added a comment -

          Committed to trunk too. Thanks for the patch Anoop.

          Show
          stack added a comment - Committed to trunk too. Thanks for the patch Anoop.
          Hide
          Lars Hofhansl added a comment -

          Awesome. Thanks Anoop and Stack.

          Show
          Lars Hofhansl added a comment - Awesome. Thanks Anoop and Stack.
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK #3277 (See https://builds.apache.org/job/HBase-TRUNK/3277/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1377366)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK #3277 (See https://builds.apache.org/job/HBase-TRUNK/3277/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1377366) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Ted Yu added a comment -

          Looks like there has been hanging test since this JIRA went in, including QA run:
          https://builds.apache.org/job/PreCommit-HBASE-Build/2695/console

          Show
          Ted Yu added a comment - Looks like there has been hanging test since this JIRA went in, including QA run: https://builds.apache.org/job/PreCommit-HBASE-Build/2695/console
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #149 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/149/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1377366)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #149 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/149/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1377366) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Ted Yu added a comment - I haven't seen the following test fail for quite some time: https://builds.apache.org/job/PreCommit-HBASE-Build/2696//testReport/org.apache.hadoop.hbase.regionserver/TestColumnSeeking/testDuplicateVersions/
          Hide
          Ted Yu added a comment -

          Trunk build has hung 4 times in a row since this went in.
          Suggest rolling back for further investigation.

          Show
          Ted Yu added a comment - Trunk build has hung 4 times in a row since this went in. Suggest rolling back for further investigation.
          Hide
          Ted Yu added a comment -

          Since there was no Hadoop QA report on this JIRA, it is very hard to determine what effect Anoop's original patch would have on trunk.

          Show
          Ted Yu added a comment - Since there was no Hadoop QA report on this JIRA, it is very hard to determine what effect Anoop's original patch would have on trunk.
          Hide
          Ted Yu added a comment -

          About the following change:

          -    HFileScanner scanner = r.getHFileReader().getScanner(true, true, false);
          +    HFileScanner scanner = r.getScanner(true, true, false);
          

          the following method is deprecated:

              public HFileScanner getScanner(boolean cacheBlocks, boolean pread,
                  boolean isCompaction) {
          

          See the javadoc:

               * Warning: Do not write further code which depends on this call. Instead
               * use getStoreFileScanner() which uses the StoreFileScanner class/interface
               * which is the preferred way to scan a store with higher level concepts.
          
          Show
          Ted Yu added a comment - About the following change: - HFileScanner scanner = r.getHFileReader().getScanner( true , true , false ); + HFileScanner scanner = r.getScanner( true , true , false ); the following method is deprecated: public HFileScanner getScanner( boolean cacheBlocks, boolean pread, boolean isCompaction) { See the javadoc: * Warning: Do not write further code which depends on this call. Instead * use getStoreFileScanner() which uses the StoreFileScanner class/ interface * which is the preferred way to scan a store with higher level concepts.
          Hide
          stack added a comment -

          Thanks Ted. I backed it out of trunk for now.

          Show
          stack added a comment - Thanks Ted. I backed it out of trunk for now.
          Hide
          stack added a comment -

          I started a build on 0.94 to see if has same issue.

          Show
          stack added a comment - I started a build on 0.94 to see if has same issue.
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK #3281 (See https://builds.apache.org/job/HBase-TRUNK/3281/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader; REVERT (Revision 1377483)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK #3281 (See https://builds.apache.org/job/HBase-TRUNK/3281/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader; REVERT (Revision 1377483) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Lars Hofhansl added a comment -

          I do not see this change in 0.94...?

          Show
          Lars Hofhansl added a comment - I do not see this change in 0.94...?
          Hide
          Lars Hofhansl added a comment -

          This also makes me want to push out of 0.94. I'll at least move it to 0.94.3.

          Show
          Lars Hofhansl added a comment - This also makes me want to push out of 0.94. I'll at least move it to 0.94.3.
          Hide
          Ted Yu added a comment -

          Since I got some finding w.r.t. HBASE-6477, I am rerunning test suite without patch for 6477 but with trunk patch for this JIRA.

          Will report back whether the build passes.

          Show
          Ted Yu added a comment - Since I got some finding w.r.t. HBASE-6477 , I am rerunning test suite without patch for 6477 but with trunk patch for this JIRA. Will report back whether the build passes.
          Hide
          Ted Yu added a comment -

          Hit HBASE-6667 in the test run

          Show
          Ted Yu added a comment - Hit HBASE-6667 in the test run
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #150 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/150/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader; REVERT (Revision 1377483)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #150 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/150/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader; REVERT (Revision 1377483) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          stack added a comment -

          Try against hadoopqa again. Uses deprecated API but nothing yet that can be used in its stead (can work on this when we remove the deprecated API).

          Show
          stack added a comment - Try against hadoopqa again. Uses deprecated API but nothing yet that can be used in its stead (can work on this when we remove the deprecated API).
          Hide
          Hadoop QA added a comment -

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

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

          +1 tests included. The patch appears to include 3 new or modified tests.

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

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

          -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings).

          -1 findbugs. The patch appears to introduce 13 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.coprocessor.TestRegionServerCoprocessorExceptionWithAbort
          org.apache.hadoop.hbase.security.access.TestAccessController

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

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12542687/5997v3_trunk.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. -1 javadoc. The javadoc tool appears to have generated 94 warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 13 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.coprocessor.TestRegionServerCoprocessorExceptionWithAbort org.apache.hadoop.hbase.security.access.TestAccessController Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2709//console This message is automatically generated.
          Hide
          stack added a comment -

          Retry

          Show
          stack added a comment - Retry
          Hide
          Hadoop QA added a comment -

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

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

          +1 tests included. The patch appears to include 3 new or modified tests.

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

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

          -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings).

          -1 findbugs. The patch appears to introduce 14 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.TestLocalHBaseCluster

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

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12542718/5997v3_trunk.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. -1 javadoc. The javadoc tool appears to have generated 106 warning messages. -1 javac. The applied patch generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 14 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.TestLocalHBaseCluster Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2713//console This message is automatically generated.
          Hide
          stack added a comment -

          So, it looks like this patch doesn't hang tests (that maybe it hbase-6477). OK I add this to trunk and 0.94 (even though I'd thought I'd done 0.94 last time)?

          Show
          stack added a comment - So, it looks like this patch doesn't hang tests (that maybe it hbase-6477). OK I add this to trunk and 0.94 (even though I'd thought I'd done 0.94 last time)?
          Hide
          ramkrishna.s.vasudevan added a comment -

          @Stack/@Ted
          Do let me know if you want me to check on this. Anoop is on vacation . Our internal CI which runs on 0.94 does not report any error and it is running fine for quite a few days.

          Show
          ramkrishna.s.vasudevan added a comment - @Stack/@Ted Do let me know if you want me to check on this. Anoop is on vacation . Our internal CI which runs on 0.94 does not report any error and it is running fine for quite a few days.
          Hide
          Anoop Sam John added a comment -

          @Stack - Sorry I was out of work for some time. So this patch does not make the test case to hang right? Pls let me know whether I need to check some thing.

          Show
          Anoop Sam John added a comment - @Stack - Sorry I was out of work for some time. So this patch does not make the test case to hang right? Pls let me know whether I need to check some thing.
          Hide
          stack added a comment -

          Retrying v3 against hadoopqa

          Show
          stack added a comment - Retrying v3 against hadoopqa
          Hide
          stack added a comment -

          Retrying Anoops patch since it was another issue hanging tests.

          Show
          stack added a comment - Retrying Anoops patch since it was another issue hanging tests.
          Hide
          stack added a comment -

          @Anoop How dare you go on vacation! (smile). Retrying the patch against hadoopqa... if passes will commit.

          Show
          stack added a comment - @Anoop How dare you go on vacation! (smile). Retrying the patch against hadoopqa... if passes will commit.
          Hide
          Hadoop QA added a comment -

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

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

          +1 tests included. The patch appears to include 3 new or modified tests.

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

          +1 javadoc. The javadoc tool did not generate any warning messages.

          -1 javac. The patch appears to cause mvn compile goal to fail.

          -1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail.

          +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.mapreduce.TestLoadIncrementalHFiles
          org.apache.hadoop.hbase.client.TestFromClientSide
          org.apache.hadoop.hbase.replication.TestReplication

          Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2847//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2847//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12544599/5997v3_trunk.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The patch appears to cause mvn compile goal to fail. -1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail. +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.mapreduce.TestLoadIncrementalHFiles org.apache.hadoop.hbase.client.TestFromClientSide org.apache.hadoop.hbase.replication.TestReplication Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2847//testReport/ Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2847//console This message is automatically generated.
          Hide
          stack added a comment -

          Committed to trunk. I think its fine being in trunk only. Speak up Lars if you want it on 0.94.

          Thanks for the patch Anoop. Good digging.

          Show
          stack added a comment - Committed to trunk. I think its fine being in trunk only. Speak up Lars if you want it on 0.94. Thanks for the patch Anoop. Good digging.
          Hide
          stack added a comment -

          Oh, I ran the tests that failed in the above locally and all passed.

          Show
          stack added a comment - Oh, I ran the tests that failed in the above locally and all passed.
          Hide
          Lars Hofhansl added a comment -

          Well... If you ask this way... Let's have it in 0.94 as well. So that this logic is correct.
          getRowOrBefore is deprecated, but it is still there, and folks can use it.

          Show
          Lars Hofhansl added a comment - Well... If you ask this way... Let's have it in 0.94 as well. So that this logic is correct. getRowOrBefore is deprecated, but it is still there, and folks can use it.
          Hide
          stack added a comment -

          Committed to 0.94 toooooo

          Show
          stack added a comment - Committed to 0.94 toooooo
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK #3322 (See https://builds.apache.org/job/HBase-TRUNK/3322/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383788)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK #3322 (See https://builds.apache.org/job/HBase-TRUNK/3322/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383788) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Hudson added a comment -

          Integrated in HBase-0.94 #464 (See https://builds.apache.org/job/HBase-0.94/464/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792)

          Result = FAILURE
          stack :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-0.94 #464 (See https://builds.apache.org/job/HBase-0.94/464/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792) Result = FAILURE stack : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Hudson added a comment -

          Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #169 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/169/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383788)

          Result = FAILURE
          stack :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #169 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/169/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383788) Result = FAILURE stack : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Hudson added a comment -

          Integrated in HBase-0.94-security #52 (See https://builds.apache.org/job/HBase-0.94-security/52/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792)

          Result = SUCCESS
          stack :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-0.94-security #52 (See https://builds.apache.org/job/HBase-0.94-security/52/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792) Result = SUCCESS stack : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          Hudson added a comment -

          Integrated in HBase-0.94-security-on-Hadoop-23 #8 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/8/)
          HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792)

          Result = FAILURE
          stack :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Show
          Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #8 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/8/ ) HBASE-5997 Fix concerns raised in HBASE-5922 related to HalfStoreFileReader (Revision 1383792) Result = FAILURE stack : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/HalfStoreFileReader.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/TestHalfStoreFileReader.java
          Hide
          stack added a comment -

          Fix up after bulk move overwrote some 0.94.2 fix versions w/ 0.95.0 (Noticed by Lars Hofhansl)

          Show
          stack added a comment - Fix up after bulk move overwrote some 0.94.2 fix versions w/ 0.95.0 (Noticed by Lars Hofhansl)

            People

            • Assignee:
              Anoop Sam John
              Reporter:
              ramkrishna.s.vasudevan
            • Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development