Mailing-List: contact hbase-user-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-user@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of jdcryans@gmail.com designates
 74.125.83.48 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=YMRg1lD9urY2KoMQJt6ykCQJtVGfhb6IKxard02tlY7lTysG5sieRnwShscaHijTBz
         oQ3MFPVRCHNkd9sm8ECw6Zk8sB9s+nDCoVddXwuQoW88kvs8QcG8k4vnAGM83nnu7mNn
         Gx+AIxIy+bl8/leQSu+qe4/94LibApioHHnj4=
MIME-Version: 1.0
Sender: jdcryans@gmail.com
In-Reply-To: <4BBD79D7.4010405@gmx.de>
References: <4BBD79D7.4010405@gmx.de>
Date: Thu, 8 Apr 2010 09:39:34 -0700
Message-ID: <y2p31a243e71004080939u482daf8as6f61907131f004bc@mail.gmail.com>
Subject: Re: HTable Client RS caching
From: Jean-Daniel Cryans <jdcryans@apache.org>
To: hbase-user@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 7, 2010 at 11:38 PM, Al Lias <al.lias@gmx.de> wrote:
> Occationally my HTable clients get a response that no server is serving
> a particular region...
> Normally, the region is back a few seconds later (perhaps a split?).

Or the region moved.

>
> Anyway, the client (Using HTablePool) seems to need a restart to forget
> this.

Seems wrong, would love a stack trace.

>
> Is there a config value to manipulate the caching time of regionserver
> assignments in the client?

Nope, when the client sees a NSRE, it queries .META. to find the new locati=
on.

>
> I set a small value for hbase.client.pause to get failures fast. I am
> using 0.20.3 .

Splits are still kinda slow, takes at least 2 seconds to happen, but
finding the new location of a region is a core feature in HBase and
it's rather well tested, Can you pin down your exact problem? Next
time a NSRE happens, see which region it was looking for and grep the
master log for it, you should see the history and how much time it
took to move.

>
> Thx,
>
> =A0Al
>