JBoss.orgCommunity Documentation

Chapter 21. TorqueBox Production Tips

21.1. Clustering
21.1.1. Enabling Clustering
21.1.2. Multicast Out of the Box
21.1.3. Don't Bind to 0.0.0.0
21.2. Clustering TorqueBox Without Multicast
21.2.1. Clustering On Amazon EC2
21.2.2. HornetQ Configuration
21.3. Sizing Number of HTTP Threads to Connection Pool
21.3.1. Setting Database Connection Pool Size
21.3.2. Setting Max Number of HTTP Threads
21.4. SSL Configuration
21.4.1. SSL Termination at Load Balancer
21.4.2. SSL Termination at TorqueBox
21.5. JVM Tuning
21.5.1. CodeCache
$ torquebox run --clustered

If you're starting JBoss AS7 directly via standalone.sh, you'll need to pass the server-config option to enable clustering.

$ $JBOSS_HOME/bin/standalone.sh --server-config=standalone-ha.xml

The --clustered option to torquebox run just chooses the standalone-ha.xml configuration for you under the covers. So, if you need to edit any of the underlying AS7 configuration the file's location is $JBOSS_HOME/standalone/configuration/standalone-ha.xml.

In either case, you'll know TorqueBox is running in clustered mode when you see something like the output below in the console upon startup.

10:38:17,118 INFO  [stdout] (ServerService Thread Pool -- 86)
10:38:17,118 INFO  [stdout] (ServerService Thread Pool -- 86) ------------------------------------------------------------------
10:38:17,118 INFO  [stdout] (ServerService Thread Pool -- 86) GMS: address=node2/web, cluster=web, physical address=192.168.1.163:55300
10:38:17,119 INFO  [stdout] (ServerService Thread Pool -- 86) -------------------------------------------------------------------

When additional nodes are started and become connected to the other nodes, you will seem something like the following in the console of both nodes:

10:38:17,226 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,null) ISPN000094: Received new cluster view: [node1/web|1] [node1/web, node2/web]
10:38:18,362 INFO  [org.hornetq.core.server.cluster.impl.BridgeImpl] (Thread-7 (HornetQ-server-HornetQServerImpl::serverUUID=e40c150a-7d0d-11e2-81a7-c54946823213-1095366819)) Bridge ClusterConnectionBridge@2d9efd57 [name=sf.my-cluster.41849c5b-7d0e-11e2-b6fc-f37690770a10, queue=QueueImpl[name=sf.my-cluster.41849c5b-7d0e-11e2-b6fc-f37690770a10, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=e40c150a-7d0d-11e2-81a7-c54946823213]]@210a7227 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@2d9efd57 [name=sf.my-cluster.41849c5b-7d0e-11e2-b6fc-f37690770a10, queue=QueueImpl[name=sf.my-cluster.41849c5b-7d0e-11e2-b6fc-f37690770a10, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=e40c150a-7d0d-11e2-81a7-c54946823213]]@210a7227 targetConnector=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=5545&host=192-168-1-163], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1368605238 [nodeUUID=e40c150a-7d0d-11e2-81a7-c54946823213, connector=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=5445&host=192-168-1-163, address=jms, server=HornetQServerImpl::serverUUID=e40c150a-7d0d-11e2-81a7-c54946823213])) [initialConnectors=[org-hornetq-core-remoting-impl-netty-NettyConnectorFactory?port=5545&host=192-168-1-163], discoveryGroupConfiguration=null]] is connected

This indicates that the two nodes have successfully connected as part of the cluster.

By default when you start TorqueBox in clustered mode other members of the cluster are discovered using multicast. Sometimes this isn't the desired behavior, either because the environment doesn't support multicast or the administrator wants direct control over the members of a cluster. In these cases, it's possible to configure TorqueBox to use a predefined set of cluster members.

Under the hood TorqueBox uses a library called JGroups to handle the cluster discovery and transports. An example of configuring TorqueBox services to cluster without multicast is below.


When running under load in production and against a database, you'll want to size the number of HTTP threads concurrently processing web requests based on the number of connections available in your database connection pool so you don't have too many requests waiting to grab a connection from the pool and timing out. The specific ratio of HTTP threads to database connection pool size will depend on your application, but a good starting point is 1 to 1.