[
https://issues.apache.org/jira/browse/HBASE-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14540877#comment-14540877
]
Hudson commented on HBASE-13662:
--------------------------------
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #937 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/937/])
HBASE-13662 RSRpcService.scan() throws an OutOfOrderScannerNext if the scan has
a retriable failure (matteo.bertozzi: rev
4d86e22492057d971c5815b75bff1f9860288767)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestScannerRetriableFailure.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> RSRpcService.scan() throws an OutOfOrderScannerNext if the scan has a
> retriable failure
> ---------------------------------------------------------------------------------------
>
> Key: HBASE-13662
> URL: https://issues.apache.org/jira/browse/HBASE-13662
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.0.1, 1.1.0, 0.98.10.1
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1
>
> Attachments: HBASE-13662-v0.patch, HBASE-13662-v1.patch
>
>
> while fixing HBASE-13651 I noticed that if we have a failure inside the
> RSRpcService.scan(), when the request has a hasNextCallSeq() the nextCallSeq
> is incremented and not rolledback, which means that the client retry will
> send a request with a nextCallSeq not up to date, which result in an
> OutOfOrderScannerNextException.
> {code}
> if (rows > 0) {
> if (request.hasNextCallSeq()) {
> if (request.getNextCallSeq() != rsh.nextCallSeq) {
> throw new OutOfOrderScannerNextException(...)
> }
> // Increment the nextCallSeq value which is the next expected from client.
> rsh.nextCallSeq++;
> }
> }
> try {
> ...scan code...
> }
> {code}
> after the scanner heartbeat patches HBASE-13090, we seems to be able to
> recover from that OutOfOrder exception, but the error show up anyway.
> After a discussion with [[email protected]] we ended up saying that
> decrementing the callSeq on exception seems to be fine. but we had the open
> question about having that nextCallSeq to be atomic, if that was supposed to
> prevent concurrent requests with the same id. any thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
