Example setting dynamic metrics on a cluster

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 is 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.

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:

<subsystem xmlns=”urn:jboss:domain:modcluster:1.0″>
<mod-cluster-config advertise-socket=”mod_cluster”>
<dynamic-load-provider history=”10″ decay=”2″>
<load-metric type=”heap” weight=”2″ />
<load-metric type=”mem” weight=”1″ />
<load-metric type=”cpu” weight=”1″ />
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:

<load-metric type=”heap” weight=”2″ capacity=”512″/>
And to the second one a low capacity:
<load-metric type=”heap” weight=”2″ capacity=”1″/>

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: https://docs.jboss.org/author/display/AS71/High+Availability+Guide

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

  • Session bean clustering
  • Entity clustering
  • Web application clustering

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: @Clustered(loadBalancePolicy=”FirstAvailable”)

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 {
. . . .

And, this is the corresponding cache-container that uses a distributed cache:
<cache-container name=”custom-sfsb” default-cache=”dist-cache”>
<distributed-cache owners=”3″ mode=”ASYNC” name=”dist”
<locking isolation=”REPEATABLE_READ”/>

0 Responses on Example setting dynamic metrics on a cluster"

Leave a Message

Your email address will not be published. Required fields are marked *

Copy Rights Reserved © Mindmajix.com All rights reserved. Disclaimer.