You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stephen Jiang <sy...@gmail.com> on 2015/03/31 23:00:10 UTC
Question on DisableTableHandler#handleDisableTable()
In DisableTableHandler#handleDisableTable(), we do the following:
(1). Set the table state to DISABLING
(2). Try to mark all regions of table (based on in-memory state of the
active master) to offline
(3). If 2 succeed, then set the table state to DISABLED
My question is if (2) failed, it would continue to co-processor post
operation and complete the process() call. This will leave the table in
DISABLING state without letting user know that the operation actually
fails. Is this desired behavior?
Thanks
Stephen
Re: Question on DisableTableHandler#handleDisableTable()
Posted by Stephen Jiang <sy...@gmail.com>.
The DisableTableHandler#handleDisableTable() is doing a while(true) loop
for retrying Step (2) - marking regions offline; however, if there is an
InterruptedException exception, it would exit the loop and continue
co-processor
post operation and complete the process() call without rethrowing the
exception.
Once Procedure V2 is implemented, we can leverage the proc results to do
retry; instead of just checking whether the table is disabled in a loop
from client-side.
My main question is that
"is current behavior desired? If (2) failed with InterruptedException
exception, should we
- rethrow the InterruptedException
- or doing some rollback - reset the table state back to ENABLED
"
Thanks
Stephen
On Tue, Mar 31, 2015 at 3:06 PM, Enis Söztutar <en...@apache.org> wrote:
> I was talking about the server side in DisableTableHandler, specifically
> BulkDisabler.
>
> In case of the client side retry, we can now (with procv2) inspect the
> status of the disable table operation and if it failed retry. Previously,
> there was no way.
>
> Enis
>
> On Tue, Mar 31, 2015 at 2:56 PM, Stephen Jiang <sy...@gmail.com>
> wrote:
>
> > There is no retry in DisableTableHandler code.
> >
> > The sync version of disableTable (HBaseAdmin.java) waits a long period
> and
> > kept checking whether the table is disabled, even the DisableTableHandler
> > already completes and it does not know. After long wait, it would
> > throw RegionException. It is up to the caller of the disableTable to do
> > retry.
> >
> > The async version, my guess is that the application code would do the
> same
> > as the sync version of logic.
> >
> > Thanks
> > Stephen
> >
> > On Tue, Mar 31, 2015 at 2:11 PM, Enis Söztutar <en...@apache.org> wrote:
> >
> >> We retry (2) until it succeeds or master is stopped (in which case the
> >> new master takes over), no?
> >>
> >> On Tue, Mar 31, 2015 at 2:00 PM, Stephen Jiang <syuanjiangdev@gmail.com
> >
> >> wrote:
> >>
> >>> In DisableTableHandler#handleDisableTable(), we do the following:
> >>> (1). Set the table state to DISABLING
> >>> (2). Try to mark all regions of table (based on in-memory state of the
> >>> active master) to offline
> >>> (3). If 2 succeed, then set the table state to DISABLED
> >>>
> >>> My question is if (2) failed, it would continue to co-processor post
> >>> operation and complete the process() call. This will leave the table
> in
> >>> DISABLING state without letting user know that the operation actually
> >>> fails. Is this desired behavior?
> >>>
> >>> Thanks
> >>> Stephen
> >>>
> >>
> >>
> >
>
Re: Question on DisableTableHandler#handleDisableTable()
Posted by Enis Söztutar <en...@apache.org>.
I was talking about the server side in DisableTableHandler, specifically
BulkDisabler.
In case of the client side retry, we can now (with procv2) inspect the
status of the disable table operation and if it failed retry. Previously,
there was no way.
Enis
On Tue, Mar 31, 2015 at 2:56 PM, Stephen Jiang <sy...@gmail.com>
wrote:
> There is no retry in DisableTableHandler code.
>
> The sync version of disableTable (HBaseAdmin.java) waits a long period and
> kept checking whether the table is disabled, even the DisableTableHandler
> already completes and it does not know. After long wait, it would
> throw RegionException. It is up to the caller of the disableTable to do
> retry.
>
> The async version, my guess is that the application code would do the same
> as the sync version of logic.
>
> Thanks
> Stephen
>
> On Tue, Mar 31, 2015 at 2:11 PM, Enis Söztutar <en...@apache.org> wrote:
>
>> We retry (2) until it succeeds or master is stopped (in which case the
>> new master takes over), no?
>>
>> On Tue, Mar 31, 2015 at 2:00 PM, Stephen Jiang <sy...@gmail.com>
>> wrote:
>>
>>> In DisableTableHandler#handleDisableTable(), we do the following:
>>> (1). Set the table state to DISABLING
>>> (2). Try to mark all regions of table (based on in-memory state of the
>>> active master) to offline
>>> (3). If 2 succeed, then set the table state to DISABLED
>>>
>>> My question is if (2) failed, it would continue to co-processor post
>>> operation and complete the process() call. This will leave the table in
>>> DISABLING state without letting user know that the operation actually
>>> fails. Is this desired behavior?
>>>
>>> Thanks
>>> Stephen
>>>
>>
>>
>
Re: Question on DisableTableHandler#handleDisableTable()
Posted by Stephen Jiang <sy...@gmail.com>.
There is no retry in DisableTableHandler code.
The sync version of disableTable (HBaseAdmin.java) waits a long period and
kept checking whether the table is disabled, even the DisableTableHandler
already completes and it does not know. After long wait, it would
throw RegionException. It is up to the caller of the disableTable to do
retry.
The async version, my guess is that the application code would do the same
as the sync version of logic.
Thanks
Stephen
On Tue, Mar 31, 2015 at 2:11 PM, Enis Söztutar <en...@apache.org> wrote:
> We retry (2) until it succeeds or master is stopped (in which case the new
> master takes over), no?
>
> On Tue, Mar 31, 2015 at 2:00 PM, Stephen Jiang <sy...@gmail.com>
> wrote:
>
>> In DisableTableHandler#handleDisableTable(), we do the following:
>> (1). Set the table state to DISABLING
>> (2). Try to mark all regions of table (based on in-memory state of the
>> active master) to offline
>> (3). If 2 succeed, then set the table state to DISABLED
>>
>> My question is if (2) failed, it would continue to co-processor post
>> operation and complete the process() call. This will leave the table in
>> DISABLING state without letting user know that the operation actually
>> fails. Is this desired behavior?
>>
>> Thanks
>> Stephen
>>
>
>
Re: Question on DisableTableHandler#handleDisableTable()
Posted by Enis Söztutar <en...@apache.org>.
We retry (2) until it succeeds or master is stopped (in which case the new
master takes over), no?
On Tue, Mar 31, 2015 at 2:00 PM, Stephen Jiang <sy...@gmail.com>
wrote:
> In DisableTableHandler#handleDisableTable(), we do the following:
> (1). Set the table state to DISABLING
> (2). Try to mark all regions of table (based on in-memory state of the
> active master) to offline
> (3). If 2 succeed, then set the table state to DISABLED
>
> My question is if (2) failed, it would continue to co-processor post
> operation and complete the process() call. This will leave the table in
> DISABLING state without letting user know that the operation actually
> fails. Is this desired behavior?
>
> Thanks
> Stephen
>