You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Vidhyashankar Venkataraman <vi...@yahoo-inc.com> on 2011/05/20 00:37:45 UTC
Hbase 2077 status?
I had spoken a while back about this problem (clients timing out when scanners do not return with a row yet: search for "A possible bug in the scanner. "
I am trying to fix the problem in the next few days: our system is a little crippled without the fix (We use filters in scans and the bug crops up during filters that return sparse sets.).
JD, can you let me know the status of the recentmost patch attached (31/Mar/10)?
Thank you
Vidhya
Re: Hbase 2077 status?
Posted by Jean-Daniel Cryans <jd...@apache.org>.
It is, but I'm trying to give you solutions until we get that fixed.
In any case, you will hit your task timeout at some point anyway.
J-D
On Thu, May 19, 2011 at 4:09 PM, Vidhyashankar Venkataraman
<vi...@yahoo-inc.com> wrote:
>>> maybe you could bump the timeouts high enough so that you don't
>>> hit the issue at all?
> Don't you think setting a high timeout might be a little ad hoc? This might just work except that it could lead to a really long delay during cases when there should be a timeout. Also we have non-homogeneous data, the timeout setting may have to be set differently for different access sizes.
>
> I can go through the patch and ping you guys back.
>
> Vidhya
>
> On 5/19/11 3:42 PM, "Jean-Daniel Cryans" <jd...@apache.org> wrote:
>
> The latest patch would need some more work, I did more than what's
> really required.
>
> If you are really taking more than a minute to do a single next()
> call, maybe you could bump the timeouts high enough so that you don't
> hit the issue at all? The default is pretty arbitrary.
>
> J-D
>
> On Thu, May 19, 2011 at 3:37 PM, Vidhyashankar Venkataraman
> <vi...@yahoo-inc.com> wrote:
>> I had spoken a while back about this problem (clients timing out when scanners do not return with a row yet: search for "A possible bug in the scanner. "
>>
>> I am trying to fix the problem in the next few days: our system is a little crippled without the fix (We use filters in scans and the bug crops up during filters that return sparse sets.).
>>
>> JD, can you let me know the status of the recentmost patch attached (31/Mar/10)?
>>
>> Thank you
>> Vidhya
>>
>
>
Re: Hbase 2077 status?
Posted by Himanshu Vashishtha <hv...@cs.ualberta.ca>.
Hey, I am also facing the similar issue but in a different context (related
to coprocessor), but that's a totally different use case (still need to look
in to it).
But in this case, will reducing the scanner cache size helps (at least
temporarily)? In a case when scanner is busy collecting/computing rows just
to meet up the cache limit expectations.
Himanshu
On Thu, May 19, 2011 at 5:09 PM, Vidhyashankar Venkataraman <
vidhyash@yahoo-inc.com> wrote:
> >> maybe you could bump the timeouts high enough so that you don't
> >> hit the issue at all?
> Don't you think setting a high timeout might be a little ad hoc? This might
> just work except that it could lead to a really long delay during cases when
> there should be a timeout. Also we have non-homogeneous data, the timeout
> setting may have to be set differently for different access sizes.
>
> I can go through the patch and ping you guys back.
>
> Vidhya
>
> On 5/19/11 3:42 PM, "Jean-Daniel Cryans" <jd...@apache.org> wrote:
>
> The latest patch would need some more work, I did more than what's
> really required.
>
> If you are really taking more than a minute to do a single next()
> call, maybe you could bump the timeouts high enough so that you don't
> hit the issue at all? The default is pretty arbitrary.
>
> J-D
>
> On Thu, May 19, 2011 at 3:37 PM, Vidhyashankar Venkataraman
> <vi...@yahoo-inc.com> wrote:
> > I had spoken a while back about this problem (clients timing out when
> scanners do not return with a row yet: search for "A possible bug in the
> scanner. "
> >
> > I am trying to fix the problem in the next few days: our system is a
> little crippled without the fix (We use filters in scans and the bug crops
> up during filters that return sparse sets.).
> >
> > JD, can you let me know the status of the recentmost patch attached
> (31/Mar/10)?
> >
> > Thank you
> > Vidhya
> >
>
>
Re: Hbase 2077 status?
Posted by Vidhyashankar Venkataraman <vi...@yahoo-inc.com>.
>> maybe you could bump the timeouts high enough so that you don't
>> hit the issue at all?
Don't you think setting a high timeout might be a little ad hoc? This might just work except that it could lead to a really long delay during cases when there should be a timeout. Also we have non-homogeneous data, the timeout setting may have to be set differently for different access sizes.
I can go through the patch and ping you guys back.
Vidhya
On 5/19/11 3:42 PM, "Jean-Daniel Cryans" <jd...@apache.org> wrote:
The latest patch would need some more work, I did more than what's
really required.
If you are really taking more than a minute to do a single next()
call, maybe you could bump the timeouts high enough so that you don't
hit the issue at all? The default is pretty arbitrary.
J-D
On Thu, May 19, 2011 at 3:37 PM, Vidhyashankar Venkataraman
<vi...@yahoo-inc.com> wrote:
> I had spoken a while back about this problem (clients timing out when scanners do not return with a row yet: search for "A possible bug in the scanner. "
>
> I am trying to fix the problem in the next few days: our system is a little crippled without the fix (We use filters in scans and the bug crops up during filters that return sparse sets.).
>
> JD, can you let me know the status of the recentmost patch attached (31/Mar/10)?
>
> Thank you
> Vidhya
>
Re: Hbase 2077 status?
Posted by Jean-Daniel Cryans <jd...@apache.org>.
The latest patch would need some more work, I did more than what's
really required.
If you are really taking more than a minute to do a single next()
call, maybe you could bump the timeouts high enough so that you don't
hit the issue at all? The default is pretty arbitrary.
J-D
On Thu, May 19, 2011 at 3:37 PM, Vidhyashankar Venkataraman
<vi...@yahoo-inc.com> wrote:
> I had spoken a while back about this problem (clients timing out when scanners do not return with a row yet: search for "A possible bug in the scanner. "
>
> I am trying to fix the problem in the next few days: our system is a little crippled without the fix (We use filters in scans and the bug crops up during filters that return sparse sets.).
>
> JD, can you let me know the status of the recentmost patch attached (31/Mar/10)?
>
> Thank you
> Vidhya
>