On Wed, May 16, 2012 at 2:40 PM, Dave Revell <[email protected]> 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 hedge. > 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)
