[
https://issues.apache.org/jira/browse/HBASE-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290783#comment-13290783
]
Anoop Sam John commented on HBASE-5974:
---------------------------------------
{quote}
As for the compatibility code: I think the useCallSeq flag has to be at a wider
scope than this. Having it in ScannerCallable means that each individual scan
will print a warning (and have to do an extra round trip), which is too much.
{quote}
I totally agree with you Todd. I thought about this while making the patch. I
couldn't find an apt place for saving this info and making use. This is scan
specific so should be some where in the scan code area I felt. Also my worry
was can it be like in one cluster itself one RS is with new code and another
with old?
Any Suggestions Todd.. As you said, extra round trip is a worry..
{quote}
I don't think we should be trying to lock down internal APIs like
RegionScanner. Coprocessors are an advanced interface and I think we should not
endeavour to provide full compatibility between versions for them.
{quote}
Rather than the compatability at interface level my worry is RegionScanner
handling this seq maintain and checking job.
In our scenario we wanted custom behaviour in RegionScanner. So what we have
done is created a new RegionScanner impl wrapping the actual RegionScanner
object created by the HRegion. Our custom impl class implements all the methods
and for the actual work we delegate the call. The extra steps we wanted to do,
we are doing before this delegation.
Now we need to add a new method in the RegionScanner [like
checkAndIncrement(seqNo)] which should be called by HRS.. Now in our usecase,
we need to implement this and may be delegate the call. Making this very much
internal item exposed to user was my worry. Hope I make it clear. We dont have
any usecase like making full custom RegionScanner impl (without even the
wrapped object) now. I dont know someone might really need some thing like
that.[But at least the CP allows to do so now] In such a thing this impl of
seqNo check need to be handled by that code itself.
> 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
> Assignee: Anoop Sam John
> Priority: Critical
> Fix For: 0.96.0, 0.94.1
>
> Attachments: 5974_94-V4.patch, 5974_trunk.patch,
> HBASE-5974_0.94.patch, HBASE-5974_94-V2.patch, HBASE-5974_94-V3.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
