I'd say add some sort of durable queue to receive the alert if you don't want to miss a message.
Essentially use a region server observer and write the alert to your favorite pub/sub solution.
The key then is starting the pub/sub queue, first so that your region server can connect to it.
If you want to get fancy, there's a bit of overkill that you could do... like figure out a way to write the output to HDFS if that made sense.
Just some thoughts before I'm really awake...
On Feb 5, 2013, at 10:45 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
> You are better off using your own RPC. Thrift would be a good choice.
> On Tuesday, February 5, 2013, Jan Althaus wrote:
>> Sorry for breaking the thread. It seems my subscription wasn't active at
>> the time the reply was posted.
>> The client receiving the notifications would be a separate process,
>> potentially on a different machine. It could obviously connect to the HBase
>> cluster though.
>> I can certainly see how delivering such notifications would be outside the
>> scope of HBase, but I wanted to make sure that I wasn't reinventing the
>> wheel by using a completely different RPC mechanism between the region
>> server and the servlet.
>>> Please be a little more specific about where the notifications should be
>>> Your custom RegionObserver lives on region server.
>>> I guess you want notifications to be delivered to your client, outside
>>>> I would like to feed a servlet that is serving a long polling request
>>>> notifications when certain rows in an hbase table change.
>>>> It seems that the best mechanism to achieve this would be to add a
>>>> RegionObserver. What I'm unsure about though is how to best issue the
>>>> callback. Does hbase provide an RPC mechanism that I could re-use or
>>>> I consider this a separate problem entirely? Are there alternative ways
>>>> get notified of row changes that better handle this problem?
> Best regards,
> - Andy
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)