Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of ghelmling@gmail.com
 designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU0-SMTP357AF64A30E9FB70677759B8F020@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>
Date: Tue, 22 Oct 2013 16:36:36 -0700
Message-ID: 
 <CADfYSXSH74gJoX4djTXY_DzXfA+yiGw193roxtv0hmKr8eHDyQ@mail.gmail.com>
Subject: Re: coprocessor status query
From: Gary Helmling <ghelmling@gmail.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7bf10aa819f6aa04e95cdf1d

--047d7bf10aa819f6aa04e95cdf1d
Content-Type: text/plain; charset=ISO-8859-1

>
> "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.

--047d7bf10aa819f6aa04e95cdf1d--