[
https://issues.apache.org/jira/browse/HBASE-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14540080#comment-14540080
]
stack commented on HBASE-13662:
-------------------------------
bq. ...but I still haven't figure out what is the real purpose of that
nextCallSeq
Client and Server each keep an incrementing sequence. As we progress through
the scan, these sequence numbers must match. If they do not, we throw
OutOfOrderScannerNextException rather than re-return results we have already
served or worse, mistakenly skip over a section in the scan range.
Nice test. +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 [[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)
