hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Einspanjer <deinspan...@mozilla.com>
Subject Re: HBASE-2001 and ElasticSearch
Date Tue, 08 Jun 2010 01:55:50 GMT
  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.


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
> 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

View raw message