Tuning the Middleware Services (JBoss AS 5) Part 3

Customizing the single deployment unit

In the previous example, we applied changes at EJB container level. However, this is a brute force change as it applies the new Interceptor stack on all your EJBs. You can opt for a softer solution that adds your customized domain in a *-aop.xml file along with your deployment unit.

Here’s an example, which could be used for non Transactional EJBs:

Notice the inheritBindings=false which means that this configuration overrides the default settings, otherwise the customized domain will inherit from the base bean configuration.

Introduction to the Java Messaging system

The Java Message Service (JMS) API is part of the Java EE specification and describes how to design components that create, send, receive, and read messages. JMS introduces a distributed communication that is loosely coupled, reliable, and asynchronous.

A JMS application is composed of the following parts:

• A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features. The current release of JBoss AS (5.1.0) uses JBoss Messaging system as a default provider. This provider has been replaced by the HornetQ Messaging system in release 6.0 of the application server..

• Messages are the objects that communicate information between JMS clients.

• Administered objects are preconfigured JMS objects created by an administrator for the use of clients. There are two kinds of administered objects:

° Connection factories: A connection factory is the object a client uses to create a connection with a provider. Every connection factory encapsulates a set of connection configuration parameters that has been defined by an administrator.

° Destinations: A destination is the object a client uses to specify the target of messages it produces and the source of messages it consumes. There can be two kinds of destinations: Queues and Topics. A queue is a staging area that contains messages that have been sent to a single consumer and are waiting to be read. A JMS queue guarantees that each message is processed only once. A topic, on the other hand, is a distribution mechanism for publishing messages that are delivered to multiple subscribers.

• JMS clients are the programs or components, written in the Java programming language, that produce and consume messages.

A special case of a JMS consumer is the Message Driven Bean (MDB), which is an Enterprise Java Bean that acts as a message listener for a particular queue or topic. In several aspects, MDBs resemble stateless session beans. In particular:

• MDB instances retain no data or conversational state for a specific client.

• All instances of a MDB are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently.

For this reason, you can configure the MDB pool using the same tactics we have described for the stateless pool (refer to the section named, How to configure the optimal size for stateless pool). However, top performance gains for MDBs are not achieved by the pool settings but by means of optimal configuration of administered objects (connection factories and destinations).

Entering the JBoss Messaging system

Before discussing optimal JMS settings, we need to understand how the JBoss messaging system fits into the overall application server architecture. The following image will let you understand the concept better:

As you can see, JBoss Messaging uses Java Connector’s pool as an inflow for messages which are sent by local clients (in the same JVM). The configuration of the Java Connector Architecture (JCA) pool can be found in the file <server>/deploy/ jca-jboss-beans.xml, which is based on the WorkManager pool:

In short, this is the meaning of the preceding parameters:

• maximumQueueSize: Specifies the maximum amount of work admitted in the queue.

• maximumPoolSize: Specifies the maximum number of active threads.

• keepAliveTime: Describes how long to keep threads alive after their last work (default one minute).

The configuration of the JCA thread pool is generally good for most applications so we will not spend much time on it. Similarly, you can configure JMS remote clients by means of the <server>\deploy\messaging\remoting-bisocket-service.xml file. Remote clients use the Remoting framework for connecting to the application server by means of a variety of protocols like HTTP or SSL. This can be particularly useful for situations like firewall restrictions where common JMS ports are blocked.

The most relevant parameter, as far as performance is concerned, is JBM_ clientMaxPoolSize which specifies how many connections are stored in the client pool. This basically limits how many connections/ sessions a client can open at a time.

The next section will discuss tuning the JBoss JMS provider, which is the area where you can achieve the most relevant performance gains.

Tuning JBoss JMS provider

The JBoss message provider has changed frequently with recent major releases of the application server. Former 3.x and 4.x releases were based on the JBossMq messaging system. The current release (5.x) of JBoss AS uses the JBoss Messaging framework, while upcoming releases are geared towards the new HornetQ messaging provider.

As this topic is definitely forward-looking, we will complete this topic with a sample case based on the newer (HornetQ) messaging provider.

Tuning JBoss Messaging (JBoss AS 5.x)

The JBoss Messaging provider ships by default with release 5.x of the application server. The configuration is distributed in the folder <server>/deploy/messaging, between the following files:

File	Usage
connection-factories-service.xml	Connection factory configuration file.
destinations-service.xml	Default Messaging destinations.
hsqldb-persistence-service.xml	Default hsql persistence configuration file.
jms-ds.xml	The JMS provider loader.
legacy-service.xml	Messaging Destinations deployment
	descriptor.
messaging-jboss-beans.xml	Messaging user-security policy definition.
messaging-service.xml	ServerPeer MBean configuration.
remoting-bisocket-service.xml	Standard bisocket-based Remoting service
	deployment descriptor.

As far as tuning is concerned, we are mainly interested in the Connection factory configuration file and the JMS destinations configuration file.

How do you tune the JBoss Messaging Connection factory?

A Connection factory encapsulates the JMS connections parameters and is bound in the JNDI naming service. The configuration file for Connection factories is located in the file deploy\messaging\connection-factories-service.xml.

The default non-clusterable configuration contains a bare-bones definition of the factory:

 

 

 

 

 

In order to tune your factory you can introduce the following attributes (default values are given for each attribute):

• PrefetchSize is an optional attribute that determines how many messages client side message consumers will buffer locally. Pre-fetching messages prevents the client from having to go to the server each time a message is consumed to say it is ready to receive another message. This greatly increases throughput. The default value for PrefetchSize is 15 0. Larger values give better throughput but require more memory.

• The setting DupsOKBatchSize works with the DUPS_OK_ACKNOWLEDGE JMS acknowledge mode. This means that message consumers might occasionally issue multiple acknowledgments of the messages. By setting this parameter the JMS provider determines how many acknowledgments it will buffer locally before sending. Again here there’s a tradeoff between performance (larger value) and memory (smaller value).

• The attribute SlowConsumers can be used if some of your consumers are slow at consuming messages. By setting this property to true you make sure the connection will not buffer any messages. This can be used to distribute the load of messages equally, preventing faster consumers from "capturing" all messages. However consider that this will disable client messaging buffering, for performance, always set this to false.

How do you tune JBoss Messaging destinations?

Creating a new messaging destination is just a matter of dropping a -service.xml file either in the <server>/deploy folder or in <server>/deploy/messaging.

You can fine tune your destination configuration by adding the following attributes (default values are used as attribute values):

• Fullsize — this is the maximum number of messages held by the queue or topic subscriptions in memory at any one time. When the amount of messages to be delivered exceeds the Fullsize value, the messages are moved to a temporary destination named "DownCache".

This parameter has a direct impact on the performance of your JMS application, however bear in mind that by increasing the default value the memory requirements of your application will increase accordingly. The following image shows the JVM memory graph of two different benchmarks: the first with the default Fullsize and the second with a custom value:

• DownCacheSize—as anticipated, this setting determines the max number of messages that the DownCache will hold before they are flushed to storage. This enables the write to occur as a single operation, thus aiding performance.

• PageSize—when loading messages from the queue or subscription, this is the maximum number of messages to pre-load in one single operation. Also, this element is crucial for the performance of heavy-duty JMS applications. Discovering the optimal PageSize requires some trials; you can try increasing it, until you hit a plateau, which means you have reached the optimal page size. For example, running a benchmark of 100.000 messages, each one with a payload of 1 KB, you will see that a PageSize of 5000 messages is the optimal value, using a typical developer configuration.