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

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


+
John Vines 2013-12-04, 19:33
+
Keith Turner 2013-12-04, 20:10
+
John Vines 2013-12-04, 20:21
+
Keith Turner 2013-12-04, 20:57
+
John Vines 2013-12-04, 21:02
+
Keith Turner 2013-12-04, 21:19
+
John Vines 2013-12-04, 21:30
+
Keith Turner 2013-12-04, 21:35
+
Josh Elser 2013-12-04, 21:35
+
Keith Turner 2013-12-04, 21:37
+
John Vines 2013-12-04, 22:03
+
Sean Busbey 2013-12-04, 22:15
Copy link to this message
-
Re: table.offline behavior change in 1.6.0
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+[EMAIL PROTECTED]>wrote:

> Could that explanation also go to one of the mailing lists please?
>
>
> On Wed, Dec 4, 2013 at 4:03 PM, John Vines <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >
> > > 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
+
Christopher 2013-12-04, 19:36