You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by lars hofhansl <la...@apache.org> on 2013/12/10 07:59:57 UTC
Re: Giving a chance to buggy coprocessors to clean up
+ dev list
I don't see any good reason for that.
Andy, Gary, any insights?
You can also try to place your "global" variables in shared HashMap via RegionCoprocessorEnvironment.getSharedData().
That will be automatically cleared up when all instances of a coprocessor class are gone.
-- Lars
________________________________
From: tsuna <ts...@gmail.com>
To: HBase users <us...@hbase.apache.org>
Sent: Monday, December 9, 2013 9:46 PM
Subject: Giving a chance to buggy coprocessors to clean up
Hi there,
If a coprocessor is buggy and throws an uncaught exception, it gets
removed without having its stop() method called, and it therefore
can't free up resources.
Any resources that are held by global variables (e.g. statics on a
class loaded by the coprocessor) can't be freed because of bug
HBASE-9046 (Coprocessors can't be upgraded in service reliably). And
the coprocessor can't be removed because of HBASE-9046. Therefore
there is no way that I can see to release those resources, short of
restarting the RegionServer (yikes!).
Is there any rationale behind not calling stop() when forcefully
removing the buggy coprocessor? Or should we maybe add some sort of a
cleanUp() method to give a chance to the coprocessor to save face and
die gracefully?
--
Benoit "tsuna" Sigoure
Re: Giving a chance to buggy coprocessors to clean up
Posted by Andrew Purtell <ap...@apache.org>.
Followed up on the issue.
On Tue, Dec 10, 2013 at 6:13 PM, tsuna <ts...@gmail.com> wrote:
> I filed an issue (https://issues.apache.org/jira/browse/HBASE-10119)
> and attached a proposition for a fix, which simply consists in calling
> stop() when we forcefully remove a coprocessor.
>
> On Mon, Dec 9, 2013 at 10:59 PM, lars hofhansl <la...@apache.org> wrote:
> > You can also try to place your "global" variables in shared HashMap via
> RegionCoprocessorEnvironment.getSharedData().
> > That will be automatically cleared up when all instances of a
> coprocessor class are gone.
>
> Unfortunately that's not good enough, because there may be also
> external resources that need to be released / cleaned up.
>
> --
> Benoit "tsuna" Sigoure
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Giving a chance to buggy coprocessors to clean up
Posted by Andrew Purtell <ap...@apache.org>.
Followed up on the issue.
On Tue, Dec 10, 2013 at 6:13 PM, tsuna <ts...@gmail.com> wrote:
> I filed an issue (https://issues.apache.org/jira/browse/HBASE-10119)
> and attached a proposition for a fix, which simply consists in calling
> stop() when we forcefully remove a coprocessor.
>
> On Mon, Dec 9, 2013 at 10:59 PM, lars hofhansl <la...@apache.org> wrote:
> > You can also try to place your "global" variables in shared HashMap via
> RegionCoprocessorEnvironment.getSharedData().
> > That will be automatically cleared up when all instances of a
> coprocessor class are gone.
>
> Unfortunately that's not good enough, because there may be also
> external resources that need to be released / cleaned up.
>
> --
> Benoit "tsuna" Sigoure
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Giving a chance to buggy coprocessors to clean up
Posted by tsuna <ts...@gmail.com>.
I filed an issue (https://issues.apache.org/jira/browse/HBASE-10119)
and attached a proposition for a fix, which simply consists in calling
stop() when we forcefully remove a coprocessor.
On Mon, Dec 9, 2013 at 10:59 PM, lars hofhansl <la...@apache.org> wrote:
> You can also try to place your "global" variables in shared HashMap via RegionCoprocessorEnvironment.getSharedData().
> That will be automatically cleared up when all instances of a coprocessor class are gone.
Unfortunately that's not good enough, because there may be also
external resources that need to be released / cleaned up.
--
Benoit "tsuna" Sigoure
Re: Giving a chance to buggy coprocessors to clean up
Posted by tsuna <ts...@gmail.com>.
I filed an issue (https://issues.apache.org/jira/browse/HBASE-10119)
and attached a proposition for a fix, which simply consists in calling
stop() when we forcefully remove a coprocessor.
On Mon, Dec 9, 2013 at 10:59 PM, lars hofhansl <la...@apache.org> wrote:
> You can also try to place your "global" variables in shared HashMap via RegionCoprocessorEnvironment.getSharedData().
> That will be automatically cleared up when all instances of a coprocessor class are gone.
Unfortunately that's not good enough, because there may be also
external resources that need to be released / cleaned up.
--
Benoit "tsuna" Sigoure