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
Alright, Keith explained it to me in #accumulo. You can disregard these
emails.
On Wed, Dec 4, 2013 at 4:37 PM, Keith Turner <[EMAIL PROTECTED]> wrote:

> On Wed, Dec 4, 2013 at 4:35 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>
> > In other words, the new implementation will not wait on the master to
> > acknowledge the offline() whereas the old implementation would. Right?
> >
>
> Incorrect, I just sent another email about this.
>
>
> >
> > That's not a big deal to me. Offline is now a fate operation too, right?
> I
> > think that would make me not worry even more.
> >
> >
> > On 12/4/13, 4:30 PM, John Vines 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);
> >>    }
> >>
> >>
> >>
> >> 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?