In other words, the new implementation will not wait on the master to acknowledge the offline() whereas the old implementation would. Right?

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.








Reply via email to