Could that explanation also go to one of the mailing lists please?
On Wed, Dec 4, 2013 at 4:03 PM, John Vines <[email protected]> wrote: > 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? > > >>>>>>>> > > >>>>>>>> > > >>>>>>> The old behavior did not wait. The API preserves the old > behavior. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > -- Sean
