At the moment, we want to do nothing more than execute a callback
function *after* a get/incr/delete has sucessfully completed. If the
callback fails to execute for some reason, we'd want to log an error,
but wouldn't want it to have any impact on the HBase side of things.
This is an extremely light-weight use-case for your coprocessors.
Originally, I had prototyped some code using Spring AOP to dynamically
hook into the regionserver code. I think this might work, and the
advantage with it is that it doesn't require any code changes to HBase,
just inclusion of Spring libraries. That said, the solution isn't
really very useful to other people the way your coprocessors are, so I
want to try to balance what is right for us with what is helpful to the
community at large.
-Daniel
On 6/7/10 9:51 PM, Andrew Purtell wrote:
Hi Daniel,
My concern is that if we don't take advantage of your
coprocessor work, we will end up needing to write our
own callback code from scratch anyway, and that doesn't
seem to be a better choice than helping you flesh out a
solid use case for co-processors and implement it.
Thoughts?
Well yes I certainly would agree with that.
This is only about streaming edits to ES in as timely a manner as possible? Or
is there more?
If ES fails to respond, you want to commit to HBase anyway, or defer and retry?
We are not imposing any policies about API or library use in the coprocessors,
nor considering weaving any CPU or heap allocation checking/limiting code at
this time. However in the future this will change. We can avoid gotchas while
working through the details.
- Andy
