hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Jiang <syuanjiang...@gmail.com>
Subject Re: Question on DisableTableHandler#handleDisableTable()
Date Wed, 01 Apr 2015 07:25:09 GMT
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 <enis@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 <syuanjiangdev@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 <enis@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
> >>>
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message