JBOSS Dynamic Metrics

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.

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:

HTTPS://DOCS.JBOSS.ORG/AUTHOR/DISPLAY/AS71/HIGH+AVAILABILITY+GUIDE

Frequently asked Jboss Interview Questions

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.
@Stateless
@Clustered
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 load balancing 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:

@Stateful
@Clustered
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:

@Stateful
@CacheConfig(name=”custom-sfsb”)
@Clustered
public class ClusteredBean {
. . . .
}