jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Scalability of JCR observation
Date Wed, 17 Apr 2013 00:35:10 GMT
When mentioning AMQ, I forgot to mention that one size doesn't fit all use
cases. When I first connected AMQ to Jackrabbit observation via OSGi
events, AMQ rapidly became swamped with the volume of events. OSGi events
were just about able to cope but as soon as the events were propagated over
the network the volume was too great. I had to filter. Oak observa

In the unlikely event that has not been considered, it might change the
thinking about the nature of the underlying infrastructure as well
as separating high volume local messages from cluster wide distribution. I
would still plead for reusing an existing best of breed solution with the
right license and sustainability, if possible. If not, an API layer so
deployers can replace the distributed messaging part with
their preferred solution.

Ian


On 17 April 2013 00:26, 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
> cluster.
>
> Just my 2 cents
> Dominik
>
> [0]http://markmail.org/thread/w3kgl7jxvhki3oqj
>
>
> On Tue, Apr 16, 2013 at 11:51 AM, Michael Dürig <mduerig@apache.org>
> 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=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13401328
> >
> >
> > Michael
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message