Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6161611CE5 for ; Tue, 5 Aug 2014 01:23:12 +0000 (UTC) Received: (qmail 20206 invoked by uid 500); 5 Aug 2014 01:23:12 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 20104 invoked by uid 500); 5 Aug 2014 01:23:12 -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 20091 invoked by uid 99); 5 Aug 2014 01:23:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Aug 2014 01:23:12 +0000 Date: Tue, 5 Aug 2014 01:23:12 +0000 (UTC) From: "Devaraj Das (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-11667) Simplify ClientScanner logic for NSREs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-11667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14085626#comment-14085626 ] Devaraj Das commented on HBASE-11667: ------------------------------------- [~lhofhansl], HBASE-11665 is tracking failures in the TestRegionReplicas. For scan tests you should run TestReplicasClient tests - that has tests for scans with replicas. Will have a look at your patch. > Simplify ClientScanner logic for NSREs. > --------------------------------------- > > Key: HBASE-11667 > URL: https://issues.apache.org/jira/browse/HBASE-11667 > Project: HBase > Issue Type: Improvement > Reporter: Lars Hofhansl > Assignee: Lars Hofhansl > Fix For: 0.99.0, 0.98.5, 2.0.0, 0.94.23 > > Attachments: 11667-0.94.txt, 11667-trunk.txt > > > We ran into an issue with Phoenix where a RegionObserver coprocessor intercepts a scan and returns an aggregate (in this case a count) with a fake row key. It turns out this does not work when the {{ClientScanner}} encounters NSREs, as it uses the last key it saw to reset the scanner to try again (which in this case would be the fake key). > While this is arguably a rare case and one could also argue that a region observer just shouldn't do this... While looking at {{ClientScanner}}'s code I found this logic not necessary. > A NSRE occurred because we contacted a region server with a key that it no longer hosts. This is the start key, so it is always correct to retry with this same key. That simplifies the ClientScanner logic and also make this sort of coprocessors possible, -- This message was sent by Atlassian JIRA (v6.2#6252)