hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: EndPoint Coprocessor could be dealocked?
Date Wed, 16 May 2012 22:28:54 GMT
On Wed, May 16, 2012 at 2:40 PM, Dave Revell <dave@urbanairship.com> wrote:
> Many people will probably try to use coprocessors as a way of implementing
> app logic on top of HBase without the headaches of writing a daemon.
> Sometimes client-side approaches are inadvisable; for example, there may be
> several client languages/runtimes and the app logic should not be
> reimplemented in each.

No, but abstracting to a common client library seems reasonable for
many cases, or building a DAO, which may happen anyway if you want to

> It's understandable that people wouldn't want to deal with setting up a
> daemon and RPC mechanism if they can piggyback on the existing HBase
> coprocessor mechanism.

Which they can certainly if the scope of access within the
RegionObserver is the region.

> Are HBase coprocessors explicitly wrong for this use case if the app logic
> needs to access multiple regions in a single call?

Not coprocessors in general. The client side support for Endpoints
(Exec, etc.) gives the developer the fiction of addressing the cluster
as a range of rows, and will parallelize per-region Endpoint
invocations, and collect the responses, and can return them all to the
caller as "a single call". However for RegionObservers, if you want to
do something cross-region, so therefore issue one or more RPCs which
must complete *before you can complete the RPC* you are currently
processing, then this is inherently problematic and deadlock prone. If
on the other hand you schedule the cross-region work with an Executor
or similar and return on the current RPC, that would be ok.

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet
Hein (via Tom White)

View raw message