Sure
<vines> let me explain <kturner> did you see my latest email? <vines> yes\ <kturner> about looking at offline(String, boolean wait) <vines> That's what has me confused <vines> yeah, I looked at it <vines> So the wait value will be used for watching the state change in ZK <vines> I get that <kturner> wait is not passed to doTableOperation <vines> No <vines> if (wait) <vines> waitForTableStateTransition(tableId, TableState.OFFLINE); <vines> at the end of the method <kturner> yeah, thats extra is wait is set to true <kturner> when wait = false, it does the same thing at 1.5 <vines> You said in one of the emails that 1.4 and 1.5 only wait for a ZK state change. From that, I inferred that the waitForTableOperation will not complete when all tablets are offline <vines> Is that not correct? <kturner> in 1.4, 1.5, and 1.6 offline(String) will synchronously execute a FATE operation that changes the table state in zookeeper <kturner> after the table state is changes, the master will start telling tablet servers to unload tabelts <kturner> tablets <kturner> in 1.6 you can optionally wait for all tablets to be unloaded <vines> But in 1.6, all wait is used for is waitForTableStateTransition <kturner> In 1.4, 1.5, and 1.6 offline(String) will only start the process of unloading tablets <vines> Which is the ZK flag to take tablets offline <kturner> waitForTableStateTransition() is a new method in 1.6... it scans the metadata table an waits until no tablet has a location On Wed, Dec 4, 2013 at 5:15 PM, Sean Busbey <[email protected]>wrote: > 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 >
