Message listener service custom properties
Use this panel to view or change an optional set of name and value pairs for custom properties of the message listener service.
To view this console page, click...
Servers | Application Servers | application_server | [Communications] Messaging | Message Listener Service | Custom PropertiesYou can use the Custom properties page to define the following properties for use by the message listener service.
- NON.ASF.RECEIVE.TIMEOUT
- MQJMS.POOLING.TIMEOUT
- MQJMS.POOLING.THRESHOLD
- MAX.RECOVERY.RETRIES
- RECOVERY.RETRY.INTERVAL
- NON.ASF.RECEIVE.TIMEOUT
- The timeout in milliseconds for synchronous message receives performed by message-driven bean listener sessions in the non-ASF mode of operation.
You should set this property to a non-zero value only if you want to enable the non-ASF mode of operation for all message-driven bean listeners on the appserver.
The message listener service has two modes of operation, Application Server Facilities (ASF) and non-Application Server Facilities (non-ASF).
- The ASF mode is meant to provide concurrency and transactional support for applications. For publish/subscribe message-drive beans, the ASF mode provides better throughput and concurrency, because in the non-ASF mode the listener is single-threaded.
- The non-ASF mode is mainly for use with generic JMS providers that do not support JMS ASF, which is an optional extension to the JMS specification. The non-ASF mode is also transactional but, because the path length is shorter than the ASF mode, usually provides improved performance.Use non-ASF if:
- Your generic JMS provider does not provide JMS ASF support
- You are using message-driven beans with WebSphere topic connections with the DIRECT port, because the embedded publish/subscribe broker using that port does not support XA transactions or JMS ASF.
- Message order is a strict requirement
Data type Integer Units Milliseconds Default ASF mode (custom property not created) Range 0 or greater milliseconds
- 0
- non-ASF mode is disabled
- 1 or more
- The timeout in milliseconds for non-ASF message-driven bean listener synchronous session receives
Recommended If a transaction timeout occurs, the message must recycle causing extra work. To use the non-ASF mode, set this property to lower than the transaction timeout, but leave spare at least the maximum duration of your message-driven bean's onMessage() method. For example, if your message-driven bean's onMessage() method typically takes a maximum of 10 seconds, and the transaction timeout is set to 120 seconds, you might set the NON.ASF.RECEIVE.TIMEOUT property to no more than 110000 (110000 milliseconds, that is 110 seconds).
- MQJMS.POOLING.TIMEOUT
- The number of milliseconds after which a connection in the pool is destroyed if it has not been used.
An MQSimpleConnectionManager allocates connections on a most-recently-used basis, and destroys connections on a least-recently-used basis. By default, a connection is destroyed if it has not been used for five minutes.
Data type Integer Units Milliseconds Default 5 minutes Range
- MQJMS.POOLING.THRESHOLD
- The maximum number of unused connections in the pool.
An MQSimpleConnectionManager allocates connections on a most-recently-used basis, and destroys connections on a least-recently-used basis. By default, a connection is destroyed if there are more than ten unused connections in the pool.
Data type Integer Units Number of connections Default 10 Range
- MAX.RECOVERY.RETRIES
- The maximum number of times that a listener port managed by this service tries to recover from a failure before giving up and stopping. When stopped the associated listener port is changed to the stop state. The interval between retry attempts is defined by the RECOVERY.RETRY.INTERVAL custom property.
A failure can be one of two things:
- An unexpected error has occurred when a listener port tries to get a message from the JMS provider.
- The connection between the appserver and the JMS provider has been lost, usually due to a network error.
Data type Integer Units Retry attempts Default 5 Range 0 (no retries) through 2147483647
- RECOVERY.RETRY.INTERVAL
- The time in seconds between retry attempts by a listener port to recover from a failure. The maximum number of retry attempts is defined by the MAX.RECOVERY.RETRIES custom property.
A failure can be one of two things:
- An unexpected error has occurred when a listener port tries to get a message from the JMS provider.
- The connection between the appserver and the JMS provider has been lost, usually due to a network error.
Data type Integer Units Seconds Default 60 Range 1 through 2147483647
Related tasks
Configure the message listener service
Related Reference
Message listener service properties