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

Duo Zhang commented on HBASE-18042:
-----------------------------------

The field has been introduced in all branches, even for 0.98. So I think the 
fix for AsyncHBase is straightforward? If the field is present then depend on 
the value of this field to decide if we need to go to the next region. If not, 
use the old logic.

And we also need a fix for all branches below 1.3 I think. If this field is 
present then we should not issue a new next request then. We can do it here or 
open a new issue.

Thanks.

> Client Compatibility breaks between versions 1.2 and 1.3
> --------------------------------------------------------
>
>                 Key: HBASE-18042
>                 URL: https://issues.apache.org/jira/browse/HBASE-18042
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 1.3.1
>            Reporter: Karan Mehta
>            Assignee: Karan Mehta
>
> OpenTSDB uses AsyncHBase as its client, rather than using the traditional 
> HBase Client. From version 1.2 to 1.3, the {{ClientProtos}} have been 
> changed. Newer fields are added to {{ScanResponse}} proto.
> For a typical Scan request in 1.2, would require caller to make an 
> OpenScanner Request, GetNextRows Request and a CloseScanner Request, based on 
> {{more_rows}} boolean field in the {{ScanResponse}} proto.
> However, from 1.3, new parameter {{more_results_in_region}} was added, which 
> limits the results per region. Therefore the client has to now manage sending 
> all the requests for each region. Further more, if the results are exhausted 
> from a particular region, the {{ScanResponse}} will set 
> {{more_results_in_region}} to false, but {{more_results}} can still be true. 
> Whenever the former is set to false, the {{RegionScanner}} will also be 
> closed. 
> OpenTSDB makes an OpenScanner Request and receives all its results in the 
> first {{ScanResponse}} itself, thus creating a condition as described in 
> above paragraph. Since {{more_rows}} is true, it will proceed to send next 
> request at which point the {{RSRpcServices}} will throw 
> {{UnknownScannerException}}. The protobuf client compatibility is maintained 
> but expected behavior is modified.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to