jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Scalability of JCR observation
Date Mon, 15 Apr 2013 09:00:02 GMT

I think it would be a pity if we would have to add ActiveMQ/RabbitMQ to
Oak, as it would increase implementation and configuration complexity
quite a lot. I would really like to avoid that.

As for JCR locking, I believe the current cluster storage backend
(MongoMK) can quite easily support it, without having to add
ActiveMQ/RabbitMQ or any other direct communication between cluster nodes.


On 4/15/13 10:46 AM, "julian.reschke@gmx.de" <julian.reschke@gmx.de> wrote:

>On 2013-04-15 10:32, Bertrand Delacretaz wrote:
>> Hi,
>> On Fri, Apr 12, 2013 at 3:35 PM, Michael Dürig <mduerig@apache.org>
>>> An implementation approach for backward compatible observation is to
>>>use a
>>> commit hook to record the required changes to a journal (e.g.
>>> /jcr:system/rep:observation). Observation listeners would then later
>>> generate the observation events by scrapping that journal
>> This sounds a lot like a distributed message queue...
>>> ...A somewhat open question is how this should work across the
>> So I'm wondering if using an existing distributed message queue
>> service (ActiveMQ/RabbitMQ etc) would help implement this. IIUC this
>> is only a problem in very large Oak setups, so having to install
>> additional components might not be an issue.
>Could that also help with implementing proper JCR Locking (or are we
>there already???).
>Best regards, Julian

View raw message