Gregory Chanan
2012-12-11, 21:52
Ted Yu
2012-12-11, 22:00
Andrew Purtell
2012-12-11, 22:37
Andrew Purtell
2012-12-11, 22:40
Jonathan Hsieh
2012-12-11, 22:50
lars hofhansl
2012-12-11, 23:19
Stack
2012-12-12, 07:08
Gregory Chanan
2012-12-13, 00:31
-
Proposal: Remove explicit RowLocks in 0.96Gregory Chanan 2012-12-11, 21:52
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
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.96Ted Yu 2012-12-11, 22:00
Including user mailing list.
On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]>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
>
On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]>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.96Andrew Purtell 2012-12-11, 22:37
I agree with all points. +1
On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Including user mailing list.
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >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)
On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> Including user mailing list.
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >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.96Andrew Purtell 2012-12-11, 22:40
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 <[EMAIL PROTECTED]> wrote:
> I agree with all points. +1
>
>
> On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
>> Including user mailing list.
>>
>> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
>> >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)
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 <[EMAIL PROTECTED]> wrote:
> I agree with all points. +1
>
>
> On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
>> Including user mailing list.
>>
>> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
>> >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.96Jonathan Hsieh 2012-12-11, 22:50
+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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >> >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
// [EMAIL PROTECTED]
Jon.
On Tue, Dec 11, 2012 at 2:40 PM, Andrew Purtell <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >> >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
// [EMAIL PROTECTED]
-
Re: Proposal: Remove explicit RowLocks in 0.96lars hofhansl 2012-12-11, 23:19
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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andrew Purtell <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >> >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
// [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Andrew Purtell <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
>
> > I agree with all points. +1
> >
> >
> > On Tue, Dec 11, 2012 at 2:00 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> >
> >> Including user mailing list.
> >>
> >> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >> >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
// [EMAIL PROTECTED]
-
Re: Proposal: Remove explicit RowLocks in 0.96Stack 2012-12-12, 07:08
+1
Lets do what Jon Hsieh suggests deprecating on next 0.94 release and
removing in 0.96.
St.Ack
On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]>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
>
Lets do what Jon Hsieh suggests deprecating on next 0.94 release and
removing in 0.96.
St.Ack
On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]>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.96Gregory Chanan 2012-12-13, 00:31
Thanks for the responses.
I filed HBASE-7341 for deprecating in 0.94 and will commit HBASE-7315 for
removing in 0.96 shortly.
Greg
On Tue, Dec 11, 2012 at 11:08 PM, Stack <[EMAIL PROTECTED]> wrote:
> +1
>
> Lets do what Jon Hsieh suggests deprecating on next 0.94 release and
> removing in 0.96.
>
> St.Ack
>
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >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
> >
>
I filed HBASE-7341 for deprecating in 0.94 and will commit HBASE-7315 for
removing in 0.96 shortly.
Greg
On Tue, Dec 11, 2012 at 11:08 PM, Stack <[EMAIL PROTECTED]> wrote:
> +1
>
> Lets do what Jon Hsieh suggests deprecating on next 0.94 release and
> removing in 0.96.
>
> St.Ack
>
>
> On Tue, Dec 11, 2012 at 1:52 PM, Gregory Chanan <[EMAIL PROTECTED]
> >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
> >
>
