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