Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of lars.george@gmail.com
 designates 209.85.212.173 as permitted sender)
Subject: Re: Confirming a Bug
References: <4F64EA01.7060902@gmail.com>
From: Lars George <lars.george@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: <4F64EA01.7060902@gmail.com>
Message-Id: <9DB6F21C-D61E-4B22-876F-3168A8D175B4@gmail.com>
Date: Sun, 18 Mar 2012 10:28:49 +0100
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

Hi Peter,

Could you be hitting HBASE-5121? Or even HBASE-2856?

Lars

On Mar 17, 2012, at 20:46, Peter Wolf <opus111@gmail.com> wrote:

> Hello,
>=20
> A couple of days ago, I asked about strange behavior in my "Scan.addFamili=
y reduces results" thread.
>=20
> I want to confirm that I did find a bug, and if so, how to submit a bug re=
port.
>=20
> The basic strangeness is that changing the amount of caching, changes the n=
umber of results.  In the original thread, this was confused by the fact tha=
t adding different families also changed the number of results.  We thought i=
t was a filtering problem.
>=20
> However, changing nothing but the setCaching() value changes the number of=
 results.  Furthermore, the result difference is a multiple of the setCachin=
g() value.
>=20
> Here is the pseudo code:
>=20
>        Scan scan =3D new Scan(...);
>        scan.addFamily(...);
>        Filter filter =3D ...
>        scan.setFilter(filter);
>=20
> -->     scan.setCaching(10000); <--
>=20
>        scanner =3D hTable.getScanner(scan);
>        Iterator<Result> it =3D scanner.iterator();
>        while (it.hasNext()) {
>            Result result =3D it.next();
>            ...
>        }
>=20
>=20
> Thank you
> Peter