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 22:22:14 GMT
Sure


<vines> let me explain
<kturner> did you see my latest email?
<vines> yes\
<kturner> about looking at offline(String, boolean wait)
<vines> That's what has me confused
<vines> yeah, I looked at it
<vines> So the wait value will be used for watching the state change in ZK
<vines> I get that
<kturner> wait is not passed to doTableOperation
<vines> No
<vines>    if (wait)
<vines>       waitForTableStateTransition(tableId, TableState.OFFLINE);
<vines> at the end of the method
<kturner> yeah, thats extra is wait is set to true
<kturner> when wait = false, it does the same thing at 1.5
<vines> You said in one of the emails that 1.4 and 1.5 only wait for a ZK
state change. From that, I inferred that the waitForTableOperation will not
complete when all tablets are offline
<vines> Is that not correct?
<kturner> in 1.4, 1.5, and 1.6 offline(String) will synchronously execute a
FATE operation that changes the table state in zookeeper
<kturner> after the table state is changes, the master will start telling
tablet servers to unload tabelts
<kturner> tablets
<kturner> in 1.6 you can optionally wait for all tablets to be unloaded
<vines> But in 1.6, all wait is used for is waitForTableStateTransition
<kturner> In 1.4, 1.5, and 1.6 offline(String) will only start the process
of unloading tablets
<vines> Which is the ZK flag to take tablets offline
<kturner> waitForTableStateTransition() is a new method in 1.6... it scans
the metadata table an waits until no tablet has a location


On Wed, Dec 4, 2013 at 5:15 PM, Sean Busbey <busbey+ml@clouderagovt.com>wrote:

> Could that explanation also go to one of the mailing lists please?
>
>
> On Wed, Dec 4, 2013 at 4:03 PM, John Vines <vines@apache.org> wrote:
>
> > Alright, Keith explained it to me in #accumulo. You can disregard these
> > emails.
> >
> >
> > On Wed, Dec 4, 2013 at 4:37 PM, Keith Turner <keith@deenlo.com> wrote:
> >
> > > On Wed, Dec 4, 2013 at 4:35 PM, Josh Elser <josh.elser@gmail.com>
> 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 <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.
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
>
>
>
> --
> Sean
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message