Hi, 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. Regards, Thomas On 4/15/13 10:46 AM, "[email protected]" <[email protected]> wrote: >On 2013-04-15 10:32, Bertrand Delacretaz wrote: >> Hi, >> >> On Fri, Apr 12, 2013 at 3:35 PM, Michael Dürig <[email protected]> >>wrote: >>> 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 >>>asynchronously... >> >> This sounds a lot like a distributed message queue... >> >>> ...A somewhat open question is how this should work across the >>>cluster... >> >> 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 >
