Hi, On 4/16/13 4:26 PM, "Dominik Süß" <[email protected]> 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 >cluster. +1 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... Cheers, Stefan > >Just my 2 cents >Dominik > >[0]http://markmail.org/thread/w3kgl7jxvhki3oqj > > >On Tue, Apr 16, 2013 at 11:51 AM, Michael Dürig <[email protected]> >wrote: > >> >> >> 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.** >> >>plugin.system.issuetabpanels:**comment-tabpanel#comment-**13401328<https: >>//issues.apache.org/jira/browse/OAK-150?focusedCommentId=13401328&page=co >>m.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13 >>401328> >> >> Michael >>
