Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> table.offline behavior change in 1.6.0


Copy link to this message
-
Re: table.offline behavior change in 1.6.0
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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>