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 Mon, 15 Apr 2013 21:57:49 GMT
Hi,
Embedding ActiveMQ into a bundle that spins up just like any other bundle
is relatively simple. Configuration for most of the standard topologies can
be done with a few URIs in OSGi properties, and, in general the only thing
that needs to be exported is a service to allow consumers and producers to
get hold of a connection. See [1].

In that example, used in Sling we ran as a broker network each node
maintaining its own shared nothing DB (using ActiveMQ's own file format
under Sling home). The bundle is a bit large since it embeds ActiveMQ's
libs and dependencies, but it was relatively trouble free over about 3
years of use in both standalone and clustered deployments with no
complaints from developers, QE's or deployers. It did not go into heavy
production for other reasons.

Tests from other places have shown that AMQ is good for significant
production, but I don't know if its good for really big clusters. I suspect
that those would be heterogeneous.

I don't know enough about RabbitMQ to know if you could do the same, but I
do know implementing a distributed queue or messaging infrastructure that
really works reliably when network fabric and hardware fails is non
trivial, and a project in its own right.

If AMQ is too big for Oak, then perhaps binding to javax.jms.* and
implementing a trivial Oak JMS service would allow deployers to swap out
for their favorite JMS implementation at deployment.

Ian

1
https://github.com/ieb/nakamura/tree/master/bundles/activemq/src/main/java/org/sakaiproject/nakamura/activemq


On 15 April 2013 19:19, Bertrand Delacretaz <bdelacretaz@apache.org> wrote:

> Hi,
>
> On Mon, Apr 15, 2013 at 11:00 AM, Thomas Mueller <mueller@adobe.com>
> wrote:
> > ...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...
>
> Note that I was suggesting that *for large clusters*.
>
> Having a simple self-contained setup a la runnable jar for
> small/demo/test/development instances is great, but I don't think it's
> a problem for a large cluster to require more tools to perform.
>
> I'm also not sure if adding the right tools increases implementation
> complexity - it's rather delegating hard stuff to projects which have
> already solved those issues.
>
> -Bertrand
>

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