Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAPbqGzh+D7+VQRzdHVBfE0biHcGJdBRv-+vCm5Gky7JUDjb_eA@mail.gmail.com>
References: 
 <CAPbqGzh+D7+VQRzdHVBfE0biHcGJdBRv-+vCm5Gky7JUDjb_eA@mail.gmail.com>
Date: Wed, 28 Mar 2012 09:45:04 -0700
Message-ID: 
 <CADcMMgGDB-bOUZskjm0jt439x6H1kqHf2Hwso8rFHPFaGGS+ng@mail.gmail.com>
Subject: Re: Get failing rarely by retrieving the next row
From: Stack <stack@duboce.net>
To: user@hbase.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 28, 2012 at 7:49 AM, Whitney Sorenson <wsorenson@hubspot.com> wrote:
> This happens reliably when we run large jobs against our cluster which
> perform many reads and writes, but it does not always happen on the
> same keys.
>

Interesting.  Anything you can figure about a particular key if you
dig in some?  For example, could the key be at a region boundary or
was the region moving/splitting at the time?

Once you've found a bad key, does it stay bad?  If so, that'd be
useful trying to debug.

It may have been fixed already but I've not done the research.

St.Ack