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 yuzhihong@gmail.com
 designates 209.85.160.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAKoQnDUqbUpUGrQ0fOP06yFRRD_L52UToGz2vwX00aoNs42xWg@mail.gmail.com>
References: 
 <CAKoQnDUAv0zPDS5OJEJBd+XARsgMdoJUEYF9B2p3F1zsDeM+yg@mail.gmail.com>
	<CAKoQnDUqbUpUGrQ0fOP06yFRRD_L52UToGz2vwX00aoNs42xWg@mail.gmail.com>
Date: Mon, 19 May 2014 15:13:03 -0700
Message-ID: 
 <CALte62wnkegyB_p5dD6zfk0Mf5CT62Az+SHKJekQOQbNTWqqfg@mail.gmail.com>
Subject: Re: Intermittent TableInputFormat error
From: Ted Yu <yuzhihong@gmail.com>
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=20cf30434c642a243804f9c811b9

--20cf30434c642a243804f9c811b9
Content-Type: text/plain; charset=UTF-8

Looking at the exception message, bytes field of the KeyValue had 0 length.
Among the places in KeyValue where bytes field is assigned, I find this
around line 2419 (trunk code):

    // TODO: perhaps some sanity check is needed here.

    byte [] bytes = new byte[Bytes.toInt(intBytes)];

If bytes has 0 length at time of KeyValue, we should report / bail out
early.

Cheers


On Mon, May 19, 2014 at 2:52 PM, Jim Klucar <klucar@gmail.com> wrote:

> Ted,
>
> Here are the mapper Exceptions. The first thing the mapper does is try to
> create an "EventKey" object and emit it with the value. Code snippet is in
> pastebin.
>
> http://pastebin.com/yNyBxsx3
>
> One thing we're doing that may be different is that we're continuously
> bulk-loading data into HBase.
>
>
>
>
> On Thu, May 15, 2014 at 11:19 AM, Jim Klucar <klucar@gmail.com> wrote:
>
> > Hello,
> >
> > We are running map/reduce over HBase 0.96.2-hadoop1 with TableInputFormat
> > and get an intermittent error that we can't track down. It shows up in
> > different jobs and we can reprocess the same data with no problems. Our
> > theory is that HBase may be migrating a region to a different server
> while
> > the scanner is reading it. Perhaps there is some setting we can enable to
> > prevent this?
> >
> > Here's the stack trace we get:
> > http://pastebin.com/Wh3ZBC0J
> >
> > Any insight is appreciated, let me know if you would like me to gather
> any
> > other log data.
> >
> > Thanks,
> > Jim
> >
> >
> >
> >
> >
> >
> >
>

--20cf30434c642a243804f9c811b9--