do a 0.94rc.
VPN... Hmm... Do you see any packet fragmentation/truncation?
-- Lars
- Original Message -
From: Peter Wolf
To: user@hbase.apache.org; lars.geo...@gmail.com; lars
hofhansl
Cc:
Sent: Thursday, March 22, 2012 6:01 PM
Subject: Re: Confirming a Bug
Hello again Lars and Lars
: Confirming a Bug
Hello again Lars and Lars,
Here is some additional information that may help you track this down.
I think this behavior has something to do with my VPN. My servers are on the
Amazon Cloud and I normally run my client on my laptop via a VPN (Tunnelblick:
OS X 10.7.3; Tunnelblick 3.2.3
Speculative execution is on by default.
http://hbase.apache.org/book.html#mapreduce.specex
On 3/23/12 8:04 AM, "Peter Wolf" wrote:
>Hi Michel,
>
>I agree it doesn't make sense, but then I believe we are tracking a bug.
>
>I don't know about speculative execution, but I certainly did not sw
Hi Michel,
I agree it doesn't make sense, but then I believe we are tracking a bug.
I don't know about speculative execution, but I certainly did not switch
it on.
I am just counting the number of rows that come back in the Result.
If you are interested in this, try my Unit test. I'd be ver
Peter, that doesnt make sense.
I mean I believe you in what you are saying, but don't see how a VPN in would
cause this variance in results.
Do you have any speculative execution turned on?
Are you counting just the numbers of rows in the result set, or are you using
counters in the map reduc
n your dataset at all? Does not it also happen
for smaller value of scanner caching?
Any chance that you can reproduce this in a unittest and file a jira?
If you do (specifically the test), I'll promise I'll look at it
this week :)
-- Lars (H)
____________
Thanks Peter,
will have a look today.
-- Lars
From: Peter Wolf
To: user@hbase.apache.org; lars.geo...@gmail.com; lars hofhansl
Sent: Monday, March 19, 2012 11:24 AM
Subject: Re: Confirming a Bug
Hello Lars and Lars,
Thank you for you help and attention
is week :)
-- Lars (H)
____________
From: Peter Wolf
To: user@hbase.apache.org
Sent: Sunday, March 18, 2012 7:13 AM
Subject: Re: Confirming a Bug
Hi Lars,
I don't think so... My behavior is definitely tied to the amount of
data in each Result. There definitely seem
it this week :)
>>
>>
>> -- Lars (H)
>>
>>
>>
>>
>> From: Peter Wolf
>> To: user@hbase.apache.org
>> Sent: Sunday, March 18, 2012 7:13 AM
>> Subject: Re: Confirming a Bug
>>
>> H
March 18, 2012 7:13 AM
Subject: Re: Confirming a Bug
Hi Lars,
I don't think so... My behavior is definitely tied to the amount of
data in each Result. There definitely seems to be some sort of
threshold. Changing the caching amount produces a completely repeatable
behavior. 10,000, 5,000, an
this week :)
-- Lars (H)
From: Peter Wolf
To: user@hbase.apache.org
Sent: Sunday, March 18, 2012 7:13 AM
Subject: Re: Confirming a Bug
Hi Lars,
I don't think so... My behavior is definitely tied to the amount of
data in each Result. There definitely seems
Hi Lars,
I don't think so... My behavior is definitely tied to the amount of
data in each Result. There definitely seems to be some sort of
threshold. Changing the caching amount produces a completely repeatable
behavior. 10,000, 5,000, and 1000 each produce different repeatable
results,
Hi Peter,
Could you be hitting HBASE-5121? Or even HBASE-2856?
Lars
On Mar 17, 2012, at 20:46, Peter Wolf wrote:
> Hello,
>
> A couple of days ago, I asked about strange behavior in my "Scan.addFamiliy
> reduces results" thread.
>
> I want to confirm that I did find a bug, and if so, how to
Hello,
A couple of days ago, I asked about strange behavior in my
"Scan.addFamiliy reduces results" thread.
I want to confirm that I did find a bug, and if so, how to submit a bug
report.
The basic strangeness is that changing the amount of caching, changes
the number of results. In the o
14 matches
Mail list logo
