[
https://issues.apache.org/jira/browse/HBASE-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15478784#comment-15478784
]
Enis Soztutar commented on HBASE-13662:
---------------------------------------
See HBASE-16604.
> 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
> Components: IPC/RPC, regionserver
> 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)
