hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject RE: dynamic RPC and coprocessor changes
Date Wed, 06 Oct 2010 02:30:46 GMT
Committing this stuff onto trunk the day before a feature freeze and as we move towards stability
gives me a little bit of the fear.

I completely understand that it's been worked on for quite some time and think this stuff
is awesome.  But I still wish I had more time to give it further review and to actually take
this stuff for a test spin.  Right now that's just not possible with all the work to be done
stabilizing and testing trunk (and I think time is best spent right now stabilizing the master/rs
versus new features).

Personally, I have a bunch of fairly sweeping compaction, flush, and split changes that have
been partially reviewed but I haven't had the time to push them over the finish line.  I hope
to get them in immediately after an 0.90 branch is cut and trunk becomes 0.92.  This should
be rather soon.  I'd like to see 0.92 get released in short order after 0.90 as there are
lots of changes that just have not made it into 0.90 yet.  So even if we waited to commit,
we could work hard towards the next major release (I don't think there are any major rewrites
planned)  :)

With this kind of big change and addition of new APIs, my preference would be to have it committed
early in a trunk cycle (versus immediately before a release is cut).  That way, we can play
with it ourselves, see how it works, try out some of our own ideas for usage of CPs, etc...
In doing that, I would expect there would be suggestions for changes in the API, additions
to the API, naming changes to be more clear from a non-implementer POV, etc...

By putting it in immediately before a release, the original API can't be broken, class names
can't be changed, all would need to be deprecated, etc...

The other issue I have with the current CP code that I have read is the number of new classes
introduced into existing core packages (especially clent).  Looking at some of their names,
they are generic sounding and it's not clear to me without digging in that they are part of
coprocessors.  Is it possible to move CP stuff into client.cp packages and the like?  Or prefix
with CoProc or some way to keep this stuff separated?

I apologize for dropping this on you now and if no one else feels the same, I am not going
to spoil the party.

But is it critical that this gets into 0.90 and into a release now?  Could we wait for 0.92
and get this committed in a couple weeks and allowed to mature a bit on trunk before it's


> -----Original Message-----
> From: Andrew Purtell [mailto:apurtell@apache.org]
> Sent: Tuesday, October 05, 2010 7:14 PM
> To: dev@hbase.apache.org
> Subject: dynamic RPC and coprocessor changes
> We've been nursing dynamic RPC and coprocessor changes for a couple of
> weeks now and don't see any failures beyond what are already on trunk
> with them applied.
> I was going to apply them tonight but will wait until tomorrow given
> that trunk is already disrupted a little.
> Best regards,
>     - Andy

View raw message