jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Egli <e...@adobe.com>
Subject Re: Scalability of JCR observation
Date Thu, 18 Apr 2013 08:54:50 GMT

On 4/16/13 4:26 PM, "Dominik Süß" <dominik.suess@gmail.com> wrote:

>I see some overlap with the latest work of Carsten in Sling regarding
>Discovery API[0]. Since Sling typically should work uppon JCR / Oak it
>might be good not to follow different patterns. For a combined solution I
>do think it would be great to have one pluggable mediating system instead
>of two which might have strange sideeffects for rejoin scenarios in a


If there was a jms/messaging client available in oak (pluggable) that an
implementation of the discovery.api (at the sling level..) could reuse,
that would definitely result in a more reliable 'cluster view' than having
separate mechanisms. How the 'cross cluster' aspect of the discovery's
topology would be implemented in that case is yet another question, but I
suppose it could just as well use jms cross-cluster...


>Just my 2 cents
>On Tue, Apr 16, 2013 at 11:51 AM, Michael Dürig <mduerig@apache.org>
>> On 15.4.13 9:46, Julian Reschke wrote:
>>> On 2013-04-15 10:32, Bertrand Delacretaz wrote:
>>  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???).
>> Probably. The idea of making external coordinaters pluggable has come up
>> before: https://issues.apache.org/**jira/browse/OAK-150?**
>> focusedCommentId=13401328&**page=com.atlassian.jira.**
>> Michael

View raw message