Thanks for the details Andrew. You might want to do a cut&past of your message and put it there => http://hbase.apache.org/book/cp.html I think it might be good to provide more information on what are the constraints, what are the pros and cons, etc.
2014-03-15 19:56 GMT-04:00 Ted Yu <[email protected]>: > I went over the thread JMS pointed to. > Gary H has responded there. As he said: > > bq. not many HBase contributors actually participate here. You will get a > much better response on the HBase users mailing list > > Cheers > > > On Sat, Mar 15, 2014 at 4:42 PM, Andrew Purtell <[email protected]> > wrote: > > > I think a misunderstanding of what we want to accomplish is the issue. > > > > We designed coprocessors to function as in-server extensions for HBase > core > > developers and system integrators. Specifically, we wanted to flexibly > > extend server functions through composition rather than use the brittle > and > > inflexible class inheritance way which was done up to that point. I think > > you can look at our security coprocessors as the canonical example of > > extensions as coprocessor done successfully. There is also Apache > Phoenix. > > There are also a few coprocessor success stories at every Hadoop or HBase > > conference I have been at since they went in. > > > > Explicitly, we have a non-goal of trying to be OSGi-type-friendly for > > random user applications. Frankly, coprocessors are not meant for loading > > *and* unloading extensions. They are meant for loading extensions over > the > > lifetime of the regionserver. There are a lot of corner cases we just > don't > > have to care about and spend time on if coprocessor extensions > effectively > > have the same lifecycle as the RegionServer. They live within the > > RegionServer process and can do just about anything, so can we really > > guarantee any state changes they might make deliberately or through > > implementation bugs can be cleaned up upon unload? No. > > > > > > > > On Sat, Mar 15, 2014 at 4:16 PM, Jean-Marc Spaggiari < > > [email protected]> wrote: > > > > > History is here: > > > > > > > > > http://www.linkedin.com/groupItem?view=&gid=1407857&type=member&item=5849626646549659651&trk=groups_most_recent-0-b-cmr&goback=.gmr_1407857 > > > > > > Not sure but I think you need to register to the group to read it. > > > > > > Basically, people often complains about coprocs. Like, can not reload > > them > > > dynamically, need to change the jars names, not well implemented, etc. > > > > > > However, it's still there, and others are using it. > > > > > > The only time I thought about using it, I have been convinced to not do > > it > > > and ended up using another solution. > > > > > > So was wondering what is the situation around coprocessors. > > > > > > Hope it's more clear now. > > > > > > JM > > > > > > > > > 2014-03-15 18:50 GMT-04:00 Andrew Purtell <[email protected]>: > > > > > > > On Sat, Mar 15, 2014 at 2:40 PM, Jean-Marc Spaggiari < > > > > [email protected]> wrote: > > > > > > > > > This caught my attention on the LinkedIn HBase group: > > > > > > > > > > "Coprocessors are not well thought out or implemented in HBase. " > > > > > > > > > > > > > I'm sorry, but dropping a disparaging statement like that without > > context > > > > or explanation is the definition of trolling J-M. > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > > > > > - Andy > > > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > > Hein > > > > (via Tom White) > > > > > > > > > > > > > > > -- > > Best regards, > > > > - Andy > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > (via Tom White) > > >
