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 <[email protected]> wrote: > Hi, > > On Mon, Apr 15, 2013 at 11:00 AM, Thomas Mueller <[email protected]> > 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 >
