Internal Metadata scan timeouts

[John Vines <vi...@apache.org>]

I bumped into a bug with ACCUMULO-676, which has to do with offlining a
tserver & logger on a single node instance. Specifically, they get jammed
up on a scan of the !METADATA table to ensure that nothing else still needs
the logger ( http://pastebin.com/m8Q3ZTTn ). There's a quick fix there
which is to not do the !METADATA check if there are no tservers. But this
leads to a slightly larger potential issue of !METADATA scans failing
perpetually with no oppertunity for error handling. There are some
instances where you want to do retries. But at some point, the error needs
to be kicked back to a higher level for it to handle (whether or not it
retries immediately is up to the specific case).

However, this seems like something that would have been broached before, so
perhaps there is some reasoning for it here that I'm overlooking. Any
thoughts before I open up a gargantuan ticket to broach this subject?

John

Re: Internal Metadata scan timeouts

[John Vines <vi...@apache.org>]

This is for writing of init.d scripts, so having it shut down teh whole
shebang is overkill IMO. With the fix I made today, it works fine.

It's moreso the larger consideration if there are other cases where we do
metadata scans with no possibility of feedback to the caller.

John

On Wed, Aug 22, 2012 at 2:30 PM, Eric Newton <er...@gmail.com> wrote:

> The Repo should probably switch to shutdown mode when you have only one
> tserver.  However, it's a little surprising that your master goes into
> "clean shutdown" mode when you ask for one server to go offline.
>
> I wouldn't bother with a new ticket.  Its not an issue for 1.5 and it's a
> silly case.
>
> -Eric
>
> On Wed, Aug 22, 2012 at 11:28 AM, John Vines <vi...@apache.org> wrote:
>
> > I bumped into a bug with ACCUMULO-676, which has to do with offlining a
> > tserver & logger on a single node instance. Specifically, they get jammed
> > up on a scan of the !METADATA table to ensure that nothing else still
> needs
> > the logger ( http://pastebin.com/m8Q3ZTTn ). There's a quick fix there
> > which is to not do the !METADATA check if there are no tservers. But this
> > leads to a slightly larger potential issue of !METADATA scans failing
> > perpetually with no oppertunity for error handling. There are some
> > instances where you want to do retries. But at some point, the error
> needs
> > to be kicked back to a higher level for it to handle (whether or not it
> > retries immediately is up to the specific case).
> >
> > However, this seems like something that would have been broached before,
> so
> > perhaps there is some reasoning for it here that I'm overlooking. Any
> > thoughts before I open up a gargantuan ticket to broach this subject?
> >
> > John
> >
>

Re: Internal Metadata scan timeouts

[Eric Newton <er...@gmail.com>]

The Repo should probably switch to shutdown mode when you have only one
tserver.  However, it's a little surprising that your master goes into
"clean shutdown" mode when you ask for one server to go offline.

I wouldn't bother with a new ticket.  Its not an issue for 1.5 and it's a
silly case.

-Eric

On Wed, Aug 22, 2012 at 11:28 AM, John Vines <vi...@apache.org> wrote:

> I bumped into a bug with ACCUMULO-676, which has to do with offlining a
> tserver & logger on a single node instance. Specifically, they get jammed
> up on a scan of the !METADATA table to ensure that nothing else still needs
> the logger ( http://pastebin.com/m8Q3ZTTn ). There's a quick fix there
> which is to not do the !METADATA check if there are no tservers. But this
> leads to a slightly larger potential issue of !METADATA scans failing
> perpetually with no oppertunity for error handling. There are some
> instances where you want to do retries. But at some point, the error needs
> to be kicked back to a higher level for it to handle (whether or not it
> retries immediately is up to the specific case).
>
> However, this seems like something that would have been broached before, so
> perhaps there is some reasoning for it here that I'm overlooking. Any
> thoughts before I open up a gargantuan ticket to broach this subject?
>
> John
>