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