accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: table.offline behavior change in 1.6.0
Date Wed, 04 Dec 2013 21:02:18 GMT
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.


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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message