hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Marc Spaggiari <jean-m...@spaggiari.org>
Subject Re: Are coprocessor really bad?
Date Sun, 16 Mar 2014 01:52:08 GMT
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 <yuzhihong@gmail.com>:

> 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 <apurtell@apache.org>
> 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 <
> > jean-marc@spaggiari.org> 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 <apurtell@apache.org>:
> > >
> > > > On Sat, Mar 15, 2014 at 2:40 PM, Jean-Marc Spaggiari <
> > > > jean-marc@spaggiari.org> 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)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message