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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected] > > > >> 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 > >>> > >> > >> > > >
