Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <BLU0-SMTP4389DBD3E5AF9832188D21E8F030@phx.gbl>
References: 
 <OF0768FDFF.DDA95B90-ON85257C0B.0076C01E-85257C0B.007725F2@us.ibm.com>
 <BLU0-SMTP2698AE14A79370091138FEB8F020@phx.gbl>
 <CADfYSXQ-z-yzc-RNc=-P_zopd+BVsJBe+UfK_YMObgi83hzmJw@mail.gmail.com>
 <BLU0-SMTP357AF64A30E9FB70677759B8F020@phx.gbl>
 <CADfYSXSH74gJoX4djTXY_DzXfA+yiGw193roxtv0hmKr8eHDyQ@mail.gmail.com>
 <OF9CDC158F.261A58BA-ON85257C0D.001C739C-85257C0D.001CA68D@us.ibm.com>
 <BLU0-SMTP4389DBD3E5AF9832188D21E8F030@phx.gbl>
From: Andrew Purtell <apurtell@apache.org>
Date: Wed, 23 Oct 2013 13:53:58 -0700
Message-ID: 
 <CA+RK=_D2Ym-hENHNcSaw9cvm0FaYWdjubFbVuQCwQghyPm=+2A@mail.gmail.com>
Subject: Re: coprocessor status query
To: "user@hbase.apache.org" <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=089e01493c5ac0f7a704e96eb995

--089e01493c5ac0f7a704e96eb995
Content-Type: text/plain; charset=ISO-8859-1

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 <michael_segel@hotmail.com>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 <wtan@us.ibm.com> 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 <ghelmling@gmail.com>
> > To:     user@hbase.apache.org,
> > 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)

--089e01493c5ac0f7a704e96eb995--