Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 12 May 2015 05:52:59 +0000 (UTC)
From: "Anoop Sam John (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12828893.1431367226000.82350.1431409979878@Atlassian.JIRA>
In-Reply-To: <JIRA.12828893.1431367226000@Atlassian.JIRA>
References: <JIRA.12828893.1431367226000@Atlassian.JIRA>
 <JIRA.12828893.1431367226227@arcas>
Subject: [jira] [Commented] (HBASE-13662) RSRpcService.scan() throws an
 OutOfOrderScannerNext if the scan has a retriable failure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Anoop Sam John commented on HBASE-13662:
----------------------------------------

+1 for rollback.
bq.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?
Requests with same scannerId and same nextSeqId will come as aresult of timeout retry from client. Concurrent same ids at server look ideally rare. Still it is ok and better to make it atomic. As Andy said.

+1 on patch.


> 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, 0.94.27, 0.98.10.1
>            Reporter: Matteo Bertozzi
>            Assignee: Matteo Bertozzi
>         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 [~saint.ack@gmail.com] 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)