Apache Camel and load balancing

Question

We plan to use Camel for making integration between some external systems (FTP, SOAP-WS, REST-WS, Topics, Queues, etc...).

We will probably use the Spring configuration (Camel context XML) and because the quantity of information is big, we plan to deploy it to a cluster of Tomcat.

I did not find any documentation if it it a possible configuration and if both applications (let says it is two tomcat for the beginning) can interfere.

UPDATE

After using Camel for three year it appears it is very well managed for some cases: 'JMS', and Web-Services, the load balancing works well in these case but in case of 'JMS', we loose the order of the messages if we do not use the header JMSXGroupID.

However the question is still open for services which consume from File (or FTP, sFTP, FTPS). For the moment we activate only one leg to consume from this source and in case the leg goes down, unfortunately there's no automatic start of the route in the second leg to consume the FTP files.

Answer 1

As long as you don't write to HTTP session you don't have to care about anything - just put some number of Tomcat nodes behind load balancer. If you write to HTTP session, that's still simple, but you probably have (depending on configuration chosen) configure session replication.

I've been working on two similar system integration projects working under heavy requests load. As a deployment environment we've chosen clustered Tomcat instances standing behind Apache servers (communicating through AJP connectors) and BigIP loadbalancer (after some time we switched to Nginx).

Both these applications accepted HTTP requests. One of them was completely stateless (proxy-like) and the other one had to keep some session-specific information. For the latter, we had to make sure that all the objects put into the session are Serializable and to configure session replication.

We've done a lot of tests, and finally ended up with battle-proven DeltaManager, no sticky sessions and synchronous replication mode. This is something that you need to consider very carefully depending on your system architecture, but there is a very good documentation that can help.

We didn't use sticky sessions because every request consisted of big processing to be done. Basis on the tests we did and the nature of requests coming, for us it was better to round-robin processing instead of hitting the same server all over again for the particular client session. Also because of no sticky session enabled, we were using synchronous replication to make sure that all nodes receive full session before the response is delivered to client (it blocks only that single request so no worries). We were not storing a huge objects in session (just some essential information), so we have no problems with that the session is replicated to all nodes by default. However, if you'll find it as a bottleneck you can refine the configuration putting some subset of nodes into clusters.