[
https://issues.apache.org/jira/browse/HBASE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13275904#comment-13275904
]
Anoop Sam John commented on HBASE-5974:
---------------------------------------
{code}
+ if (-1 != cookie && cookie != rswc.cookie) {
+ this.scanners.remove(scannerName);
+ this.leases.cancelLease(scannerName);
+ throw new ScannerCookieOutOfOrderException("Cookie from client and
cookie at server do not match");
+ }
{code}
When the cookie is out of order, we remove the scanner and cancel Lease.[Not
waiting for the lease timeout] This is in same line as what happens with NSRE.
One question which arise in my mind is do we need to contact the CP hooks of
pre and post scanner close here?
Now in normal close() of scanner from client side and lease timeout based
close, we call CP hooks. But what abt the scanner getting removed from RS when
the NSRE happens. [Same applicable to ScannerCookieOutOfOrderException case too]
> Scanner retry behavior with RPC timeout on next() seems incorrect
> -----------------------------------------------------------------
>
> Key: HBASE-5974
> URL: https://issues.apache.org/jira/browse/HBASE-5974
> Project: HBase
> Issue Type: Bug
> Components: client, regionserver
> Affects Versions: 0.90.7, 0.92.1, 0.94.0, 0.96.0
> Reporter: Todd Lipcon
> Priority: Critical
> Attachments: HBASE-5974_0.94.patch
>
>
> I'm seeing the following behavior:
> - set RPC timeout to a short value
> - call next() for some batch of rows, big enough so the client times out
> before the result is returned
> - the HConnectionManager stuff will retry the next() call to the same server.
> At this point, one of two things can happen: 1) the previous next() call will
> still be processing, in which case you get a LeaseException, because it was
> removed from the map during the processing, or 2) the next() call will
> succeed but skip the prior batch of rows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
