Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A3550200C8B for ; Mon, 22 May 2017 15:58:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A1ED5160BA5; Mon, 22 May 2017 13:58:09 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E8EC9160BBF for ; Mon, 22 May 2017 15:58:08 +0200 (CEST) Received: (qmail 86129 invoked by uid 500); 22 May 2017 13:58:08 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 86098 invoked by uid 99); 22 May 2017 13:58:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 May 2017 13:58:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 72B3DCEB5D for ; Mon, 22 May 2017 13:58:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.502 X-Spam-Level: X-Spam-Status: No, score=-99.502 tagged_above=-999 required=6.31 tests=[KAM_NUMSUBJECT=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id kvXbLoH7ZqlS for ; Mon, 22 May 2017 13:58:06 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 03F475FDBB for ; Mon, 22 May 2017 13:58:06 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 5A70EE0DBA for ; Mon, 22 May 2017 13:58:05 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 6472F21D62 for ; Mon, 22 May 2017 13:58:04 +0000 (UTC) Date: Mon, 22 May 2017 13:58:04 +0000 (UTC) From: "Duo Zhang (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18042) Client Compatibility breaks between versions 1.2 and 1.3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 22 May 2017 13:58:09 -0000 [ https://issues.apache.org/jira/browse/HBASE-18042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16019602#comment-16019602 ] Duo Zhang commented on HBASE-18042: ----------------------------------- After digging I think HBASE-17489 did break the compatibility between 1.2 and 1.3. Before branch-1.2, we only set moreResultsInRegion to false when we return empty result to client, even if moreRows returned by the RegionScanner is false. That's why we will issue one more request to a region which has already been exhausted. And in 1.3, if we set moreResultsInRegion to false when we have also reached the scan caching, the {{doneWithRegion}} will return false because the countdown is 0 thus a new request to the same region will be issued. It is easy to fix at client side. The problem of the old doneWithRegion method is that, we set serverHasMoreResults to false even if we do not have moreResultsInRegion flag in proto. Will prepare a patch soon. But I'm not sure if we also need to add some dirty code at server side to keep compatible with the old client without the new patch. I want to define this problem as a bug, but it is also a pain for users that they must upgrade to the newest version of 1.2 or 1.1 before upgrading to 1.3 only because of a 'bug' that does not break anything on 1.2 or 1.1... 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)