Maximum messages
This setting controls the maximum number of messages that the listener can process in one session. This setting will only change behavior if the JMS provider is either the MQ JMS or WebSphere JMS provider.
Component: Message Listener Applies to specific messaging topologies: No Requires specific usage of JMS in application: Yes Location of setting: Servers | Application Servers | MyAppServer | Message Listener Service | Listener Ports | MyListenerPort | Maximum messages field The MQ JMS based providers handle the starting of the MDBs transaction differently than other JMS providers.
When the JMS provider receives one or more messages it retrieves a listener port session, gets the QueueSession from it and passes the message to that QueueSession. The JMS provider then calls start on the listener port session which passes the MDB reference to the QueueSession, spins off a new message listener thread and calls run on the QueueSession. The JMS provider then delivers the message to the onMessage method of the MDB.
The difference between MQ JMS and other providers is that for MQ JMS and the Embedded JMS provider, the listener service begins the transaction before it calls run. This is because WebSphere MQ needs the transaction in order to retrieve the message, before passing it to the MDB. Other JMS providers are able to receive the message without the MDBs transaction.
This difference in behavior can be exploited using the Maximum messages setting. As the message listener service is starting the transaction it is possible to pass multiple messages to the QueueSession within the context of one transaction, rather than having to have one transaction per message. The number of messages being the value in Maximum messages. Each session will still process the messages in serial fashion.
Changing the value of Maximum messages will reduce the number of transactions that have to be created to process messages. However, this setting might not have an obvious impact on performance, and it changes the way in which those messages are handled:
- If one message in the batch fails processing with an exception, the entire batch of messages is put back on the queue for processing.
- Any resource lock held by any of the interactions for the individual messages are held for the duration of the entire batch.
- Depending on the amount of processing that messages need, and if XA transactions are being used, setting a value greater than 1 could cause the transaction to time out.
The performance improvement will not be obvious when changing this setting as messages will not necessarily be processed faster. The correct ratio between Maximum messages and Maximum sessions would need to be reached.
For example, if there 10 messages on a queue and the Maximum sessions is set to 5, Maximum messages is set to 1, then 5 messages at a time will be processed (assuming enough physical resources). If Maximum messages is set to 5 and Maximum sessions remains at 5, then 5 messages will go to the first session and 5 messages will go to the second session. This means that only 2 messages will be processed at the same time.
The workload will depict how effective changing the Maximum messages setting will be. In the example, if the number of messages is increased to 50 or more then start to see some benefit of the reduced overhead of creating transactions.
This setting is more useful when running batches of messages through WAS, rather than dealing with real time requests.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.