There was some effort in adding support for region server-based endpoint. Here is the JIRA:
https://issues.apache.org/jira/browse/HBASE-5982 Cheers On Wed, Jul 24, 2013 at 10:34 PM, lars hofhansl <[email protected]> wrote: > It's because a region is the independent unit in HBase. A region is > mobile. If you pick something larger than a region you are tying state > together that would complicate region mobility. > > There are probably other ways to design this, but from this angle it makes > sense. > If Andy Purtell is around he probably can elaborate further. > > -- Lars > > ________________________________ > From: Vladimir Rodionov <[email protected]> > To: "[email protected]" <[email protected]>; lars hofhansl < > [email protected]> > Sent: Wednesday, July 24, 2013 10:19 PM > Subject: RE: Couple notes and questions on RegionObserver's > > > Lars, I know that coprocessors are per region, I just do not understand > why: > > see all my 5 questions in my previous e-mails. > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: [email protected] > > ________________________________________ > From: lars hofhansl [[email protected]] > Sent: Wednesday, July 24, 2013 8:59 PM > To: [email protected] > Subject: Re: Couple notes and questions on RegionObserver's > > Yes, coprocessors are per region and instantiated when the region is > instantiated, which is what happens at enable. > That's by design. How else would you design it? How would you allow for > reloading updated coprocessor classes? > > -- Lars > > ________________________________ > From: Vladimir Rodionov <[email protected]> > To: "[email protected]" <[email protected]> > Sent: Wednesday, July 24, 2013 8:43 PM > Subject: RE: Couple notes and questions on RegionObserver's > > > This becomes more interesting ... > > On region.disable (Table.disable) HBase close and stops coprocessor > On region.enable (Table.enable) HBase CREATES new instance and then call > its start() > > ... thus effectively dumping all coprocessor's context and state. So, what > happens when > someone want sto update CF in hbase shell: > > disable 'Table' > > alter ..... > > enable 'Table' > > +> Welcome new coprocessor instance. > > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: [email protected] > > ________________________________________ > From: Vladimir Rodionov > Sent: Wednesday, July 24, 2013 8:31 PM > To: [email protected] > Subject: Couple notes and questions on RegionObserver's > > On design: > > Why is the instance per region if we specify region in every call to > RegionObserver anyway( through RegionCoprocessorEnvironment)? The > coprocessor instance is attached to every table region and > receives the very same region as a parameter of every call except > start/stop? > > I want one coprocessor instance per RegionServer->Table or I want one > Instance per RegionServer. Its not feasible currently? > > On implementation: > 1. stop() is always called after postClose - this one I tested > 2. start() is always called before preOpen() ? > > OK. this is annoying. The contract of start/stop becomes unclear. I though > that we start should be called on coprocessor load and > stop - on RS shutdown. > > 3. abortRequested parameter is always false. Yes, its for testing but how > can I distinguish disabling table and RS shutdown? > > 4. How can I intercept (or get notified on) RS shutdown request from > inside a coprocessor? > > and the last one: > > 5. I have one table and one region - hence one coprocessor instance. When > I disable table I observe the following sequence of calls: > > preClose > preClose > preClose > postClose > stop > > preClose is called three times in row. Is it feature or a bug? > > This was tested with MiniHBaseCluster. Hbase 0.94.6.1 > > Best regards, > Vladimir Rodionov > Principal Platform Engineer > Carrier IQ, www.carrieriq.com > e-mail: [email protected] > > Confidentiality Notice: The information contained in this message, > including any attachments hereto, may be confidential and is intended to be > read only by the individual or entity to whom this message is addressed. If > the reader of this message is not the intended recipient or an agent or > designee of the intended recipient, please note that any review, use, > disclosure or distribution of this message or its attachments, in any form, > is strictly prohibited. If you have received this message in error, please > immediately notify the sender and/or [email protected] and > delete or destroy any copy of this message and its attachments. >
