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. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> >
