Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # dev - table.offline behavior change in 1.6.0


Copy link to this message
-
Re: table.offline behavior change in 1.6.0
Keith Turner 2013-12-04, 21:35
On Wed, Dec 4, 2013 at 4:30 PM, John Vines <[EMAIL PROTECTED]> wrote:

> In 1.5, doing offline(table) will submit and wait (short wait) based on
> what you said,
>
>       doTableOperation(TableOperation.OFFLINE, args, opts);
>
> and
>
>  private String doTableOperation(TableOperation op, List<ByteBuffer> args,
> Map<String,String> opts) throws AccumuloSecurityException,
> TableExistsException,
>       TableNotFoundException, AccumuloException {
>     return doTableOperation(op, args, opts, true);
>   }
>
>
>
>
>  In 1.6, doing offline(table) will submit and have no wait based on what
> you said and
>
> public void offline(String tableName) throws AccumuloSecurityException,
> AccumuloException, TableNotFoundException {
>     offline(tableName, false);
>   }
>

Take a look at the implementation of offline(String, boolean) and you will
see that it always waits for the table operation.  The wait flag determines
if should additionally call   waitForTableStateTransition(tableId,
TableState.OFFLINE).
>
>
>
> On Wed, Dec 4, 2013 at 4:19 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Dec 4, 2013 at 4:02 PM, John Vines <[EMAIL PROTECTED]> wrote:
> >
> > > I think that's even more problematic. We go from having, by default, a
> > > short wait, by default to no wait by default and then a flag which
> > provides
> > > a long wait and no ability to get the short wait. I'm not disagreeing
> > that
> > > it should be done, but these are still behavior changes to old APIs.
> > >
> >
> > Can you show me in the code where a behavior change occurred?  I do not
> see
> > one.   In 1.5 and 1.6 offline(table) both only
> > call doTableOperation(TableOperation.OFFLINE, args, opts).    In 1.6
> > calling offline(table, true) will
> > call doTableOperation(TableOperation.OFFLINE, args, opts)
> > AND waitForTableStateTransition(tableId, TableState.OFFLINE).
> >
> >
> > >
> > >
> > > On Wed, Dec 4, 2013 at 3:57 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Wed, Dec 4, 2013 at 3:21 PM, John Vines <[EMAIL PROTECTED]> wrote:
> > > >
> > > >>  I disagree. The 1.5.0 code path waits by default. Offline() calls
> > > >> doTableOperation, which calls doTableOperation with wait=true, which
> > > >> causes waitForTableOperation to trigger. Unless there's weird casing
> > > >> for waitForTableOperation, of which there does not appear to be, it
> > will
> > > >> wait.
> > > >>
> > > >
> > > > In 1.5 and 1.4 its only waiting for the master to change the table
> > state
> > > > in zookeeper.  Its not waiting for all of the tablets to go offline.
> > > Take
> > > > a look at o.a.a.s.master.tableOps.ChangeTableState, this is what gets
> > > > executed on the master.
> > > >
> > > > 1.6 adds the ability to wait for all tablets to go offline.
> > > >
> > > >
> > > >>
> > > >>
> > > >> On Wed, Dec 4, 2013 at 3:10 PM, Keith Turner <[EMAIL PROTECTED]>
> > wrote:
> > > >>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed, Dec 4, 2013 at 2:33 PM, John Vines <[EMAIL PROTECTED]>
> wrote:
> > > >>>
> > > >>>> It has recently come to my attention that the default behavior for
> > > >>>> TableOperations.offline(table) to immediately return. There is now
> > an
> > > >>>> additional command which offers a wait flag like the old behavior.
> > > >>>> However,
> > > >>>> I'm really not comfortable changing API behavior between major
> > > releases
> > > >>>> like that. What is everyone else's thoughts on this?
> > > >>>>
> > > >>>
> > > >>> The old behavior did not wait.  The API preserves the old behavior.
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >
> > >
> >
>