accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: table.offline behavior change in 1.6.0
Date Wed, 04 Dec 2013 21:35:20 GMT
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 <keith@deenlo.com> wrote:
>
>> On Wed, Dec 4, 2013 at 4:02 PM, John Vines <vines@apache.org> 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 <keith@deenlo.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Dec 4, 2013 at 3:21 PM, John Vines <vines@apache.org> 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 <keith@deenlo.com>
>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Dec 4, 2013 at 2:33 PM, John Vines <vines@apache.org>
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.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message