Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - Couple notes and questions on RegionObserver's


Copy link to this message
-
RE: Couple notes and questions on RegionObserver's
Vladimir Rodionov 2013-07-25, 05:19
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.