Listener port settings
A listener port is used to simplify administration of the association between a connection factory, destination, and deployed message-driven bean.
To view or change the configuration properties of the selected listener port.
administrative console | Servers | Application Servers | application_server | Message Listener Service | Listener Ports | listener_port
Name The name by which the listener port is known for administrative purposes.
Data type String Default Null
Initial state The state that you want the listener port to have when the appserver is next cycled
Data type Enum Units Not applicable Default Started Range
Started When the appserver is next started, the listener port is started automatically.
Stopped When the appserver is next started, the listener port is not started automatically. If message-driven beans are to use this listener port on the application server, the system administrator must start the port manually or select the Started value of this property then restart the application server.
Description A description of the listener port, for administrative purposes within IBM WAS.
Data type String Default Null
Connection factory JNDI name The JNDI name for the JMS connection factory to be used by the listener port; for example, jms/connFactory1.
Data type String Default Null
Destination JNDI name The JNDI name for the destination to be used by the listener port; for example, jms/destn1. If the extended messaging service is to use this listener port to handle late responses, the value of this property must match the JMS response destination on the output port used by the sender bean.
You cannot use a temporary destination for late responses.
Data type String Default Null
Maximum sessions Specifies the maximum number of concurrent sessions that a listener can have with the JMS server to process messages. Each session corresponds to a separate listener thread and therefore controls the number of concurrently processed messages. Tweak when the JMS server does not fully use the available capacity of the machine and if you do not need to process messages in a specific message order.
Data type Integer Units Sessions Default 1 Range 1 through 2147483647 Recommended
- If you want to process messages in a strict message order, set the value to 1, so only one thread is ever processing messages.
- If you want to process multiple messages simultaneously (known as "message concurrency"), set this property to a value greater than 1. Keep this value as low as possible to prevent overloading client applications. A good starting point for a 100% JMS workload with short transaction times is 2 to 4 sessions per processor. If longer running transactions exist, you may need more sessions, which should be determined by experimentation.
- If you are using XA transactions, this property should always be set to 1. If it this property is set to a higher value, multiple messages are delivered in the same transaction, which is usually not the desired behavior.
Maximum retries The maximum number of times that the listener tries to deliver a message before the listener is stopped, in the range 0 through 2147483647. The maximum number of times that the listener tries to deliver a message to a message-driven bean instance before the listener is stopped.
Configure backout queues to prevent the listener port from stopping due to bad messages.
Data type Integer Units Retry attempts Default 0 (no retries) Range 0 (no retries) through 2147483647
Maximum messages The maximum number of messages that the listener can process in one session with the JMS server. For WebSphere embedded messaging or WebSphere MQ as the JMS provider, the listener processes all messages in the session as one batch within the same transaction. For a generic JMS provider, the listener processes each message in the session within a separate transaction.
Data type Integer Units Number of messages Default 1 Range 1 through 2147483647 Recommended For WebSphere embedded messaging or WebSphere MQ as the JMS provider, if you want to process multiple messages in a single transaction, then set this value to more than 1. This enables multiple messages to be batch-processed into a single transaction, and eliminates much of the overhead of transactions on JMS messages.
Note that
- 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 can cause the transaction to time out. If an XA transaction does time out routinely because processing multiple messages exceeds the transaction timeout, reduce this property to 1 (to limit processing to one message per transaction) or increase your transaction timeout.