Page History

Camel proposes different solutions to allow your solution to be scalable, to distribute the load between different instances. The choice will depend on how you will deploy/package Camel (standalone mode, embedded in a J2EE or OSGI server, ...) and how the servers will be configured (master/slave, ...).1.

Loadbalancing

This approach allows to distribute the load between different endpoints. The from endpoint plays the role of a 'proxy' when we use by example a jetty server

loadbalance() : http://camel.apache.org/load-balancer.html^{Image Removed}2.

Clustering

The clustering can be achieved in different ways : Work distribution,

...

Consumer competition,

...

...

...

depending how you would like to configure your infrastructure (one or several instances running on the same machine or distribute across a cloud of servers).2.1.

• Same JVM & CamelContext

Different Camel components can be used depending if the work must be done in a sync or async way2.1.1

• • Without persistence

Async
: seda:// : http://camel.apache.org/seda.html^{Image Removed} + threads()

Sync
: direct:// : http://camel.apache.org/direct.html^{Image Removed} + threads()2.1.2 With persistence
jms:// : http://camel.apache.org/jms.html^{Image Removed}

• Same JVM but different CamelContext

This approach is suitable for solutions running in standalone mode or deployed in Web Application Server (different WAR/EAR)

vm://

Remark : This component cannot be used between different OSGI servers

• • With persistence

JMS queue engine : jms:// + threads()
activemq:// : http://camel.apache.org/activemq.htmland^{Image Removed} Activemq queue engine : activemq:// + threads()2.2

• Different JVM & CamelContext

When the infrastructure offers the possibility to deploy the application on several machines, then you can use the approaches presented at point 2.1before. That means means that you will deploy the same application on several nodes and in this case, we have competitor consumers. Depending on the load on the servers, messages can be consume by application 1 running on Server 1 instead of application 2 running on Server 2.

If you prefer to deploy routes on different servers having different CPU/memory, then you can use the following components

2.2.1. Suitable for solutions running in standalone mode or deployed in Web Application Server (different WAR/EAR)

vm:// : http://camel.apache.org/vm.html^{Image Removed}

This component cannot be used between different OSGI servers

...

• • Within or between different instances of OSGI servers (SMX4)

nmr:// : http://camel.apache.org/nmr.html^{Image Removed}

Camel can be not only plugged on the NMR bus but can also use the clustering functionality offered by ServiceMix 4 ()4.

Cloudcomputing

...

• Cassandra
  It could be interesting to create a Cassandra endpoint to allow to consume
  info/camel messages from Cassandra DB (NOSQL database) or to push there
  camel message (using id + binary stream). It might also make an interesting
  aggregator implementation since its also distributed & can support multi-master

...

• Camel-terracotta
  Extends the SEDA component