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 <la...@apache.org> 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 <vrodio...@carrieriq.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org>; lars hofhansl < > la...@apache.org> > 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: vrodio...@carrieriq.com > > ________________________________________ > From: lars hofhansl [la...@apache.org] > Sent: Wednesday, July 24, 2013 8:59 PM > To: dev@hbase.apache.org > 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 <vrodio...@carrieriq.com> > To: "dev@hbase.apache.org" <dev@hbase.apache.org> > 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: vrodio...@carrieriq.com > > ________________________________________ > From: Vladimir Rodionov > Sent: Wednesday, July 24, 2013 8:31 PM > To: dev@hbase.apache.org > 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: vrodio...@carrieriq.com > > 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 notificati...@carrieriq.com and > delete or destroy any copy of this message and its attachments. >
