Sean Busbey commented on HBASE-22835:

bq. I think, unless 1.3 is EOM yet, there can be users who struggle with the 
same problem. Whether next release is comming or not, Reviewing and confirming 
that this is right solution still worth for them. (maybe they can build 

that's a fair take on the situation. just to make sure observers are up to 
date, the current consensus on the dev@hbase email thread "Considering 
immediate EOL of branch-1.3 and branch-1.4 " 
 is to cease releases of the 1.3.z and 1.4.z lines.

Folks who'd like to see more releases from these lines should take up the 
discussion on that thread. We're all volunteers and as an ASF project we're a 
"do-acracy". Essentially that means if there are community members who want to 
make those releases they'll happen. Right now there aren't as far as we can 
tell. Keeping those release lines active will need folks willing to be release 
managers for relevant releases. That's easiest if the volunteer is on the PMC. 
We have experience doing it if the volunteer is a committer. In theory any one 
can do it just some of the steps will take longer because of access.

> Scan/Get with setColumn and the store with ROWCOL bloom filter could throw 
> AssertionError (backport of  HBASE-19863)
> --------------------------------------------------------------------------------------------------------------------
>                 Key: HBASE-22835
>                 URL: https://issues.apache.org/jira/browse/HBASE-22835
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.3.5
>            Reporter: Jeongmin Kim
>            Priority: Major
>             Fix For: 1.3.6
>         Attachments: HBASE-22835.branch-1.3.patch, 
> HBASE-22835.v2.branch-1.3.patch, HBASE-22835.v3.branch-1.3.patch, 
> HBASE-22835.v4.branch-1.3.patch
> Scan/Get with setColumn and the store with ROWCOL bloom filter could throw 
> AssertionError of scan order check.
> which is resolved by HBASE-19863 for 1.4, 2.x, or later version.
> A same bug exists in branch 1.3 and older, and also my cluster suffered from 
> the same problem.
> When ROWCOL bloomFilter is enabled and fake cell is the prevCell,
>  actual hfs offset can be behind, in this case heap.next() is not enough. it 
> requires reseek to find right next cell.
> {code:java}
> java.lang.AssertionError: Key 
> key167/0:C09/OLDEST_TIMESTAMP/Minimum/vlen=0/seqid=0 followed by a smaller 
> key key167/0:C04/1565596231736/Put/vlen=3/seqid=4 in cf 0 at 
> org.apache.hadoop.hbase.regionserver.StoreScanner.checkScanOrder(StoreScanner.java:969)
>  at 
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:551) 
> at 
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:150) 
> at 
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.populateResult(HRegion.java:6144)
>  at 
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextInternal(HRegion.java:6307)
>  at 
> org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.nextRaw(HRegion.java:6081)
>  at 
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:2755)
>  at 
> org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:2957)
>  at 
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35072)
>  at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2394) at 
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:123) at 
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188) at 
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168) 
> {code}
> I created a backport patch of -HBASE-19863 and  *HBASE-17958*-.
> Exact same testcase included. And changed StoreScanner due to the difference 
> of codes.

This message was sent by Atlassian Jira

Reply via email to