You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Ted Yu <yu...@gmail.com> on 2012/12/11 23:00:23 UTC
Re: Proposal: Remove explicit RowLocks in 0.96
Including user mailing list.
On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gc...@cloudera.com>wrote:
> Over in HBASE-7263 there has been some discussion about removing support
> for explicit RowLocks in 0.96. This would involve the following:
> - Remove lockRow/unlockRow functions in HTable and similar
> - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> - functions in HRegion no longer take lockIds (checkAndPut, append,
> increment, etc). This would affect coprocessors that call directly into
> those functions.
>
> I have a patch in HBASE-7315 with the details.
>
> This would violate our usual rule of deprecating a feature one release
> before removing. The reasoning is as follows:
> 1) RowLocks are broken
> They are only kept in the memory associated with the region, so on a
> split, region move, RS crash, they just disappear
>
> 2) 0.96 is special
> Now seems like a good time to clean things up since we've made some
> incompatible changes already (e.g. protobufing) and we could have a cleaner
> client implementation
>
> 3) RowLocks have been deprecated "in spirit" for awhile
> Here's a post from 2009 cautioning against their use:
> http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> and a more recent example:
> http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
>
> 4) RowLocks are hard to use effectively
> Clients can deadlock or starve themselves, either by forgetting to release
> the RowLocks or by starving other non-contending row operations by
> occupying server handlers stuck waiting to acquire the locks.
>
> Thoughts?
>
> Greg
>
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
I'm not an HBase expert, but if the lock is not fully working, I don't
see the point to keep it on 0.96.x and agree with deprecating it on
0.94.4.
Also, I think Andrew's option is a very good fit. We already have
Zookeeper available, and HBase might be able to come with something
like a row lock based on Zookeeper reservation. Maybe on a later
version?
JM
2012/12/11, lars hofhansl <lh...@yahoo.com>:
> There two different questions here, right:
> 1. Remove rowlocks as a client side API (HBASE-7315)
> 2. Remove rowlocks from server code and replace it with better mechanism
> (HBASE-7263)
>
> +1 on both. And also +1 on deprecating them in 0.94.4.
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org
> Cc: Andrew Purtell <ap...@apache.org>; "user@hbase.apache.org"
> <us...@hbase.apache.org>
> Sent: Tuesday, December 11, 2012 2:50 PM
> Subject: Re: Proposal: Remove explicit RowLocks in 0.96
>
> +1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
>
> Jon.
>
> On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>> I would add another point to the reasoning:
>>
>> 5) Users can build application level rowlocks using HBase's CAS
>> primitives,
>> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
>> HBase environments), and these don't suffer the problems mentioned.
>>
>>
>> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > I agree with all points. +1
>> >
>> >
>> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
>> >
>> >> Including user mailing list.
>> >>
>> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
>> >> >wrote:
>> >>
>> >> > Over in HBASE-7263 there has been some discussion about removing
>> support
>> >> > for explicit RowLocks in 0.96. This would involve the following:
>> >> > - Remove lockRow/unlockRow functions in HTable and similar
>> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
>> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
>> >> > increment, etc). This would affect coprocessors that call directly
>> into
>> >> > those functions.
>> >> >
>> >> > I have a patch in HBASE-7315 with the details.
>> >> >
>> >> > This would violate our usual rule of deprecating a feature one
>> >> > release
>> >> > before removing. The reasoning is as follows:
>> >> > 1) RowLocks are broken
>> >> > They are only kept in the memory associated with the region, so on a
>> >> > split, region move, RS crash, they just disappear
>> >> >
>> >> > 2) 0.96 is special
>> >> > Now seems like a good time to clean things up since we've made some
>> >> > incompatible changes already (e.g. protobufing) and we could have a
>> >> cleaner
>> >> > client implementation
>> >> >
>> >> > 3) RowLocks have been deprecated "in spirit" for awhile
>> >> > Here's a post from 2009 cautioning against their use:
>> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
>> >> > and a more recent example:
>> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
>> >> >
>> >> > 4) RowLocks are hard to use effectively
>> >> > Clients can deadlock or starve themselves, either by forgetting to
>> >> release
>> >> > the RowLocks or by starving other non-contending row operations by
>> >> > occupying server handlers stuck waiting to acquire the locks.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Greg
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>> >
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Jean-Marc Spaggiari <je...@spaggiari.org>.
I'm not an HBase expert, but if the lock is not fully working, I don't
see the point to keep it on 0.96.x and agree with deprecating it on
0.94.4.
Also, I think Andrew's option is a very good fit. We already have
Zookeeper available, and HBase might be able to come with something
like a row lock based on Zookeeper reservation. Maybe on a later
version?
JM
2012/12/11, lars hofhansl <lh...@yahoo.com>:
> There two different questions here, right:
> 1. Remove rowlocks as a client side API (HBASE-7315)
> 2. Remove rowlocks from server code and replace it with better mechanism
> (HBASE-7263)
>
> +1 on both. And also +1 on deprecating them in 0.94.4.
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org
> Cc: Andrew Purtell <ap...@apache.org>; "user@hbase.apache.org"
> <us...@hbase.apache.org>
> Sent: Tuesday, December 11, 2012 2:50 PM
> Subject: Re: Proposal: Remove explicit RowLocks in 0.96
>
> +1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
>
> Jon.
>
> On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>> I would add another point to the reasoning:
>>
>> 5) Users can build application level rowlocks using HBase's CAS
>> primitives,
>> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
>> HBase environments), and these don't suffer the problems mentioned.
>>
>>
>> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > I agree with all points. +1
>> >
>> >
>> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
>> >
>> >> Including user mailing list.
>> >>
>> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
>> >> >wrote:
>> >>
>> >> > Over in HBASE-7263 there has been some discussion about removing
>> support
>> >> > for explicit RowLocks in 0.96. This would involve the following:
>> >> > - Remove lockRow/unlockRow functions in HTable and similar
>> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
>> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
>> >> > increment, etc). This would affect coprocessors that call directly
>> into
>> >> > those functions.
>> >> >
>> >> > I have a patch in HBASE-7315 with the details.
>> >> >
>> >> > This would violate our usual rule of deprecating a feature one
>> >> > release
>> >> > before removing. The reasoning is as follows:
>> >> > 1) RowLocks are broken
>> >> > They are only kept in the memory associated with the region, so on a
>> >> > split, region move, RS crash, they just disappear
>> >> >
>> >> > 2) 0.96 is special
>> >> > Now seems like a good time to clean things up since we've made some
>> >> > incompatible changes already (e.g. protobufing) and we could have a
>> >> cleaner
>> >> > client implementation
>> >> >
>> >> > 3) RowLocks have been deprecated "in spirit" for awhile
>> >> > Here's a post from 2009 cautioning against their use:
>> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
>> >> > and a more recent example:
>> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
>> >> >
>> >> > 4) RowLocks are hard to use effectively
>> >> > Clients can deadlock or starve themselves, either by forgetting to
>> >> release
>> >> > the RowLocks or by starving other non-contending row operations by
>> >> > occupying server handlers stuck waiting to acquire the locks.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Greg
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>> >
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by lars hofhansl <lh...@yahoo.com>.
There two different questions here, right:
1. Remove rowlocks as a client side API (HBASE-7315)
2. Remove rowlocks from server code and replace it with better mechanism (HBASE-7263)
+1 on both. And also +1 on deprecating them in 0.94.4.
-- Lars
________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
To: dev@hbase.apache.org
Cc: Andrew Purtell <ap...@apache.org>; "user@hbase.apache.org" <us...@hbase.apache.org>
Sent: Tuesday, December 11, 2012 2:50 PM
Subject: Re: Proposal: Remove explicit RowLocks in 0.96
+1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
Jon.
On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> I would add another point to the reasoning:
>
> 5) Users can build application level rowlocks using HBase's CAS primitives,
> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
> HBase environments), and these don't suffer the problems mentioned.
>
>
> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >> >wrote:
> >>
> >> > Over in HBASE-7263 there has been some discussion about removing
> support
> >> > for explicit RowLocks in 0.96. This would involve the following:
> >> > - Remove lockRow/unlockRow functions in HTable and similar
> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> >> > increment, etc). This would affect coprocessors that call directly
> into
> >> > those functions.
> >> >
> >> > I have a patch in HBASE-7315 with the details.
> >> >
> >> > This would violate our usual rule of deprecating a feature one release
> >> > before removing. The reasoning is as follows:
> >> > 1) RowLocks are broken
> >> > They are only kept in the memory associated with the region, so on a
> >> > split, region move, RS crash, they just disappear
> >> >
> >> > 2) 0.96 is special
> >> > Now seems like a good time to clean things up since we've made some
> >> > incompatible changes already (e.g. protobufing) and we could have a
> >> cleaner
> >> > client implementation
> >> >
> >> > 3) RowLocks have been deprecated "in spirit" for awhile
> >> > Here's a post from 2009 cautioning against their use:
> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> >> > and a more recent example:
> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >> >
> >> > 4) RowLocks are hard to use effectively
> >> > Clients can deadlock or starve themselves, either by forgetting to
> >> release
> >> > the RowLocks or by starving other non-contending row operations by
> >> > occupying server handlers stuck waiting to acquire the locks.
> >> >
> >> > Thoughts?
> >> >
> >> > Greg
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by lars hofhansl <lh...@yahoo.com>.
There two different questions here, right:
1. Remove rowlocks as a client side API (HBASE-7315)
2. Remove rowlocks from server code and replace it with better mechanism (HBASE-7263)
+1 on both. And also +1 on deprecating them in 0.94.4.
-- Lars
________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
To: dev@hbase.apache.org
Cc: Andrew Purtell <ap...@apache.org>; "user@hbase.apache.org" <us...@hbase.apache.org>
Sent: Tuesday, December 11, 2012 2:50 PM
Subject: Re: Proposal: Remove explicit RowLocks in 0.96
+1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
Jon.
On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> I would add another point to the reasoning:
>
> 5) Users can build application level rowlocks using HBase's CAS primitives,
> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
> HBase environments), and these don't suffer the problems mentioned.
>
>
> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >> >wrote:
> >>
> >> > Over in HBASE-7263 there has been some discussion about removing
> support
> >> > for explicit RowLocks in 0.96. This would involve the following:
> >> > - Remove lockRow/unlockRow functions in HTable and similar
> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> >> > increment, etc). This would affect coprocessors that call directly
> into
> >> > those functions.
> >> >
> >> > I have a patch in HBASE-7315 with the details.
> >> >
> >> > This would violate our usual rule of deprecating a feature one release
> >> > before removing. The reasoning is as follows:
> >> > 1) RowLocks are broken
> >> > They are only kept in the memory associated with the region, so on a
> >> > split, region move, RS crash, they just disappear
> >> >
> >> > 2) 0.96 is special
> >> > Now seems like a good time to clean things up since we've made some
> >> > incompatible changes already (e.g. protobufing) and we could have a
> >> cleaner
> >> > client implementation
> >> >
> >> > 3) RowLocks have been deprecated "in spirit" for awhile
> >> > Here's a post from 2009 cautioning against their use:
> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> >> > and a more recent example:
> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >> >
> >> > 4) RowLocks are hard to use effectively
> >> > Clients can deadlock or starve themselves, either by forgetting to
> >> release
> >> > the RowLocks or by starving other non-contending row operations by
> >> > occupying server handlers stuck waiting to acquire the locks.
> >> >
> >> > Thoughts?
> >> >
> >> > Greg
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Jonathan Hsieh <jo...@cloudera.com>.
+1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
Jon.
On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> I would add another point to the reasoning:
>
> 5) Users can build application level rowlocks using HBase's CAS primitives,
> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
> HBase environments), and these don't suffer the problems mentioned.
>
>
> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >> >wrote:
> >>
> >> > Over in HBASE-7263 there has been some discussion about removing
> support
> >> > for explicit RowLocks in 0.96. This would involve the following:
> >> > - Remove lockRow/unlockRow functions in HTable and similar
> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> >> > increment, etc). This would affect coprocessors that call directly
> into
> >> > those functions.
> >> >
> >> > I have a patch in HBASE-7315 with the details.
> >> >
> >> > This would violate our usual rule of deprecating a feature one release
> >> > before removing. The reasoning is as follows:
> >> > 1) RowLocks are broken
> >> > They are only kept in the memory associated with the region, so on a
> >> > split, region move, RS crash, they just disappear
> >> >
> >> > 2) 0.96 is special
> >> > Now seems like a good time to clean things up since we've made some
> >> > incompatible changes already (e.g. protobufing) and we could have a
> >> cleaner
> >> > client implementation
> >> >
> >> > 3) RowLocks have been deprecated "in spirit" for awhile
> >> > Here's a post from 2009 cautioning against their use:
> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> >> > and a more recent example:
> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >> >
> >> > 4) RowLocks are hard to use effectively
> >> > Clients can deadlock or starve themselves, either by forgetting to
> >> release
> >> > the RowLocks or by starving other non-contending row operations by
> >> > occupying server handlers stuck waiting to acquire the locks.
> >> >
> >> > Thoughts?
> >> >
> >> > Greg
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Jonathan Hsieh <jo...@cloudera.com>.
+1. Deprecate in the next 0.94.x release and remove from 0.96/trunk?
Jon.
On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <ap...@apache.org> wrote:
> I would add another point to the reasoning:
>
> 5) Users can build application level rowlocks using HBase's CAS primitives,
> or ZooKeeper / Curator recipes (since ZooKeeper is always available in
> HBase environments), and these don't suffer the problems mentioned.
>
>
> On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >> >wrote:
> >>
> >> > Over in HBASE-7263 there has been some discussion about removing
> support
> >> > for explicit RowLocks in 0.96. This would involve the following:
> >> > - Remove lockRow/unlockRow functions in HTable and similar
> >> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> >> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> >> > increment, etc). This would affect coprocessors that call directly
> into
> >> > those functions.
> >> >
> >> > I have a patch in HBASE-7315 with the details.
> >> >
> >> > This would violate our usual rule of deprecating a feature one release
> >> > before removing. The reasoning is as follows:
> >> > 1) RowLocks are broken
> >> > They are only kept in the memory associated with the region, so on a
> >> > split, region move, RS crash, they just disappear
> >> >
> >> > 2) 0.96 is special
> >> > Now seems like a good time to clean things up since we've made some
> >> > incompatible changes already (e.g. protobufing) and we could have a
> >> cleaner
> >> > client implementation
> >> >
> >> > 3) RowLocks have been deprecated "in spirit" for awhile
> >> > Here's a post from 2009 cautioning against their use:
> >> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> >> > and a more recent example:
> >> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >> >
> >> > 4) RowLocks are hard to use effectively
> >> > Clients can deadlock or starve themselves, either by forgetting to
> >> release
> >> > the RowLocks or by starving other non-contending row operations by
> >> > occupying server handlers stuck waiting to acquire the locks.
> >> >
> >> > Thoughts?
> >> >
> >> > Greg
> >> >
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
> >
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Andrew Purtell <ap...@apache.org>.
I would add another point to the reasoning:
5) Users can build application level rowlocks using HBase's CAS primitives,
or ZooKeeper / Curator recipes (since ZooKeeper is always available in
HBase environments), and these don't suffer the problems mentioned.
On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org> wrote:
> I agree with all points. +1
>
>
> On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
>
>> Including user mailing list.
>>
>> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
>> >wrote:
>>
>> > Over in HBASE-7263 there has been some discussion about removing support
>> > for explicit RowLocks in 0.96. This would involve the following:
>> > - Remove lockRow/unlockRow functions in HTable and similar
>> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
>> > - functions in HRegion no longer take lockIds (checkAndPut, append,
>> > increment, etc). This would affect coprocessors that call directly into
>> > those functions.
>> >
>> > I have a patch in HBASE-7315 with the details.
>> >
>> > This would violate our usual rule of deprecating a feature one release
>> > before removing. The reasoning is as follows:
>> > 1) RowLocks are broken
>> > They are only kept in the memory associated with the region, so on a
>> > split, region move, RS crash, they just disappear
>> >
>> > 2) 0.96 is special
>> > Now seems like a good time to clean things up since we've made some
>> > incompatible changes already (e.g. protobufing) and we could have a
>> cleaner
>> > client implementation
>> >
>> > 3) RowLocks have been deprecated "in spirit" for awhile
>> > Here's a post from 2009 cautioning against their use:
>> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
>> > and a more recent example:
>> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
>> >
>> > 4) RowLocks are hard to use effectively
>> > Clients can deadlock or starve themselves, either by forgetting to
>> release
>> > the RowLocks or by starving other non-contending row operations by
>> > occupying server handlers stuck waiting to acquire the locks.
>> >
>> > Thoughts?
>> >
>> > Greg
>> >
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Andrew Purtell <ap...@apache.org>.
I would add another point to the reasoning:
5) Users can build application level rowlocks using HBase's CAS primitives,
or ZooKeeper / Curator recipes (since ZooKeeper is always available in
HBase environments), and these don't suffer the problems mentioned.
On Tue, Dec 11, 2012 at 2:37 PM, Andrew Purtell <ap...@apache.org> wrote:
> I agree with all points. +1
>
>
> On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
>
>> Including user mailing list.
>>
>> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
>> >wrote:
>>
>> > Over in HBASE-7263 there has been some discussion about removing support
>> > for explicit RowLocks in 0.96. This would involve the following:
>> > - Remove lockRow/unlockRow functions in HTable and similar
>> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
>> > - functions in HRegion no longer take lockIds (checkAndPut, append,
>> > increment, etc). This would affect coprocessors that call directly into
>> > those functions.
>> >
>> > I have a patch in HBASE-7315 with the details.
>> >
>> > This would violate our usual rule of deprecating a feature one release
>> > before removing. The reasoning is as follows:
>> > 1) RowLocks are broken
>> > They are only kept in the memory associated with the region, so on a
>> > split, region move, RS crash, they just disappear
>> >
>> > 2) 0.96 is special
>> > Now seems like a good time to clean things up since we've made some
>> > incompatible changes already (e.g. protobufing) and we could have a
>> cleaner
>> > client implementation
>> >
>> > 3) RowLocks have been deprecated "in spirit" for awhile
>> > Here's a post from 2009 cautioning against their use:
>> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
>> > and a more recent example:
>> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
>> >
>> > 4) RowLocks are hard to use effectively
>> > Clients can deadlock or starve themselves, either by forgetting to
>> release
>> > the RowLocks or by starving other non-contending row operations by
>> > occupying server handlers stuck waiting to acquire the locks.
>> >
>> > Thoughts?
>> >
>> > Greg
>> >
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Andrew Purtell <ap...@apache.org>.
I agree with all points. +1
On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> Including user mailing list.
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >wrote:
>
> > Over in HBASE-7263 there has been some discussion about removing support
> > for explicit RowLocks in 0.96. This would involve the following:
> > - Remove lockRow/unlockRow functions in HTable and similar
> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> > increment, etc). This would affect coprocessors that call directly into
> > those functions.
> >
> > I have a patch in HBASE-7315 with the details.
> >
> > This would violate our usual rule of deprecating a feature one release
> > before removing. The reasoning is as follows:
> > 1) RowLocks are broken
> > They are only kept in the memory associated with the region, so on a
> > split, region move, RS crash, they just disappear
> >
> > 2) 0.96 is special
> > Now seems like a good time to clean things up since we've made some
> > incompatible changes already (e.g. protobufing) and we could have a
> cleaner
> > client implementation
> >
> > 3) RowLocks have been deprecated "in spirit" for awhile
> > Here's a post from 2009 cautioning against their use:
> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> > and a more recent example:
> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >
> > 4) RowLocks are hard to use effectively
> > Clients can deadlock or starve themselves, either by forgetting to
> release
> > the RowLocks or by starving other non-contending row operations by
> > occupying server handlers stuck waiting to acquire the locks.
> >
> > Thoughts?
> >
> > Greg
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Proposal: Remove explicit RowLocks in 0.96
Posted by Andrew Purtell <ap...@apache.org>.
I agree with all points. +1
On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <yu...@gmail.com> wrote:
> Including user mailing list.
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <gchanan@cloudera.com
> >wrote:
>
> > Over in HBASE-7263 there has been some discussion about removing support
> > for explicit RowLocks in 0.96. This would involve the following:
> > - Remove lockRow/unlockRow functions in HTable and similar
> > - Remove constructors for Put/Delete/Increment/Get that take RowLocks
> > - functions in HRegion no longer take lockIds (checkAndPut, append,
> > increment, etc). This would affect coprocessors that call directly into
> > those functions.
> >
> > I have a patch in HBASE-7315 with the details.
> >
> > This would violate our usual rule of deprecating a feature one release
> > before removing. The reasoning is as follows:
> > 1) RowLocks are broken
> > They are only kept in the memory associated with the region, so on a
> > split, region move, RS crash, they just disappear
> >
> > 2) 0.96 is special
> > Now seems like a good time to clean things up since we've made some
> > incompatible changes already (e.g. protobufing) and we could have a
> cleaner
> > client implementation
> >
> > 3) RowLocks have been deprecated "in spirit" for awhile
> > Here's a post from 2009 cautioning against their use:
> > http://bb10.com/java-hadoop-hbase-user/2009-09/msg00239.html
> > and a more recent example:
> > http://permalink.gmane.org/gmane.comp.java.hadoop.hbase.user/23488
> >
> > 4) RowLocks are hard to use effectively
> > Clients can deadlock or starve themselves, either by forgetting to
> release
> > the RowLocks or by starving other non-contending row operations by
> > occupying server handlers stuck waiting to acquire the locks.
> >
> > Thoughts?
> >
> > Greg
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)