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

Switch to Threaded View
HBase, mail # user - coprocessor status query


Copy link to this message
-
Re: coprocessor status query
Andrew Purtell 2013-10-23, 20:53
You are certainly welcome to your opinion. I think we have been very clear
at all possible instances that coprocessors are an *internal *extension
framework for HBase. So I would submit a DUH rather than DOA. Just saying.
On Wed, Oct 23, 2013 at 5:21 AM, Michael Segel <[EMAIL PROTECTED]>wrote:

> Well...
>
> I am biting my tongue. ;-P
>
> I could have gone on to say that unless you have a very special use case
> that can't be implemented another way, and that you are going to have a
> staff of very senior developers maintaining your implementation ... Don't
> use coprocessors.  They are really that dangerous.
>
> IMHO, the current implementation is DOA, primarily because it runs in the
> same JVM as the RS.
> (I'll have to see if I can open a JIRA and make comments.)
>
>
> On Oct 23, 2013, at 12:13 AM, Wei Tan <[EMAIL PROTECTED]> wrote:
>
> > Hi Gary, thanks for your clarification and yes, I totally agree with your
> > statement.
> >
> > The class is not removed but the CP is kind of removed and not active
> > after an un-handled exception.
> > I will take a look at the Jira you mentioned.
> > Best regards,
> > Wei
> >
> >
> >
> > From:   Gary Helmling <[EMAIL PROTECTED]>
> > To:     [EMAIL PROTECTED],
> > Date:   10/22/2013 07:37 PM
> > Subject:        Re: coprocessor status query
> >
> >
> >
> >>
> >> "The coprocessor class is of course still in memory on the
> >> regionserver,...."
> >>
> >> That was kinda my point.
> >>
> >> You can't remove the class from the RS until you do a rolling restart.
> >>
> >
> > Yes, understood.
> >
> > However, your original statement that "You can't remove a coprocessor"
> > needed some clarification, in that the coprocessor that threw the
> > exception
> > _is_ removed from the active set of coprocessors for that region.  So it
> > is
> > no longer invoked for pre/post hooks on the call path for further
> > requests.
> >
> > From the original question, I take it that this invocation context is
> what
> > Wei cared about.
> >
>
> The opinions expressed here are mine, while they may reflect a cognitive
> thought, that is purely accidental.
> Use at your own risk.
> Michael Segel
> michael_segel (AT) hotmail.com
>
>
>
>
>
>
--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)