Example setting dynamic metrics on a cluster

  • (4.0)
  •   |   400 Ratings

In the following example, we have a very simple cluster comprising two nodes. Each node has the same JVM operating defaults, and each one is running on two identical machines.

We will, however, simulate some memory-intensive operation on the first node so that the amount of heap memory used differs from one server to another:

This a very common scenario in Enterprise applications where each functionality may have a different impact on memory, for example, holding data temporarily in the HTTP session.

Enthusiastic about exploring the skill set of Jboss? Then, have a look at the JBOSS TRAINING COURSE together additional knowledge. 

In such a case, using a round-robin approach to distribute a request may, in the end, lead to an Out-of-Memory scenario on some nodes of your cluster. You can, however, mitigate this effect largely with a simple configuration of the loading metrics:

When using this configuration on both nodes, the heap memory usage has twice the impact of other enlisted metrics (operating system memory and CPU speed).

The outcome of this configuration change is that the server two collects 55 percent of the requests over the 45 percent landed on the first server:

By setting the appropriate capacity, you can further achieve a better level of granularity to node-weighting. For example, setting on the first server a higher capacity:

Then, the outcome of the test would be different, as the second server now delivers more response than the first one, counter-balancing the weight metric:

Configuring clustering in your applications

At the time of writing this book, the application clustering configuration had not been finalized in all components. Although web applications and the persistence API is ready for clustering, some components (chiefly EJB 3 session beans) are still missing clustering capabilities.

With the help of the JBoss development team, we could, however, produce all the necessary information needed for configuring clustering in your applications. As this information might be subject to change, we suggest you check the AS 7.1 documentation at:


Frequently asked Jboss Interview Questions

Now, we will complete our journey through the clustering system, discussing:

Clustering session beans

In the tutorial – Configuring Enterprise Services, we recapped the difference between
Stateless Session Beans (SLSB) and Stateful Session Beans (SFSB).
SLSB are not able to retain state between invocations, so the main benefit of clustering
an SLSB is to balance the load between an array of servers. Consequently, the clustering
policies are pretty simple and requires at most adding a @
org.jboss.ejb3.annotation.Clustered annotation.
public class ClusteredBean {
public void doSomething() {
// Do something
If you want to further specialize your SLSB, then you can choose the load-balancing
algorithm used to distribute the load between your EJBs. These are the available loadbalancing
policies for your SLSB:

Then, you can apply the load-balancing policy as in the following example:


Clustering SFSB is not too different from the stateless counterpart. At the minimum, all you have to include is a @Clustered annotation at class level:
public class ClusteredBean {
public void doSomething() {
// Do something

By default, SFSBs use the cache-container named sfsb, which replicates sessions across all nodes. Should your application server node fail while sessions are running, the EJB proxy will detect it and choose another node where session data has been replicated. You can, however, reference a custom cache container used by your SFSB

with the org.jboss.ejb3.annotation.CacheConfig annotation:
public class ClusteredBean {
. . . .

Explore Jboss Sample Resumes! Download & Edit, Get Noticed by Top Employers!Download Now!


Popular Courses in 2018

Get Updates on Tech posts, Interview & Certification questions and training schedules