WebSphere Application Server listener ports

Message-driven bean (MDB) applications that are installed in WebSphere Application Server can also use listener ports to process messages on an IBM MQ system.

Listener ports are used to detect messages arriving on an IBM MQ system, and then deliver them to MDBs for processing. This topic explains how the listener port monitors the IBM MQ system.

MDBs can also make additional connections to IBM MQ systems from inside their onMessage() method.

See Enterprise JavaBeans and web-based applications for more information on how these connections can use automatic client reconnection

• CONNECTIONNAMELIST and CCDTURL are supported with restrictions
• CLIENTRECONNECTOPTIONS is not supported

CONNECTIONNAMELIST property

Listener ports make use of JMS connection pools when connecting to IBM MQ, so are subject to the implications of using connection pools. See Activation specifications for further information.

If there are no free connections, and the maximum number of connections have not yet been created from this connection factory, the CONNECTIONNAMELIST property is used to try and create a new connection to IBM MQ.

If all the IBM MQ systems in the CONNECTIONNAMELIST are not accessible, the listener port stops.

The listener port then waits for the period of time specified by the message listener service custom property RECOVERY.RETRY.INTERVAL and tries to reconnect again.

This reconnection attempt checks if there are any free connections in the connection pool, just in case one was returned in between the connection attempts. If one is not available, the listener port uses the CONNECTIONNAMELIST as before.

Once the listener port has reconnected to an IBM MQ system, the Java EE environment performs any transactional cleanup that is required, and then resumes delivering messages to MDBs for processing.

In order for the transactional cleanup to work correctly, the Java EE environment must be able to access the logs for the queue manager that failed.

If the listener ports are being used with transactional MDBs that participate in XA transactions, and are connecting to a multi-instance queue manager, the CONNECTIONNAMELIST must contain an entry for both the active and standby queue manager instance.

This means that the Java EE environment can access the queue manager logs if the environment needs to perform transaction recovery, regardless of which queue manager the environment reconnects to following a failure.

If the transactional MDBs are being used with stand-alone queue managers, the CONNECTIONNAMELIST property must contain a single entry, to ensure that the activation specification always reconnects to the same queue manager running on the same system following a failure.

CCDTURL property

When starting, the listener port attempts to connect to the queue manager specified in the QMANAGER property using the first entry in the CCDT.

If the listener port is not able to connect to the queue manager using the first entry in the table, the listener port moves on to the second entry, and so on, until either a connection to the queue manager has been made, or the end of the table has been reached.

If the listener port is unable to connect to the specified queue manager using any of the entries in the CCDT, the listener port stops.

The listener port then waits for the period of time specified by the message listener service custom property RECOVERY.RETRY.INTERVAL and tries to reconnect again.

This reconnection attempt works its way through all of the entries in the CCDT as before.

Once the Listener Port is running, it gets messages from the IBM MQ system and delivers them to an MDB for processing.

If the queue manager fails while a message is being processed, the Java EE environment detects the failure and tries to reconnect the listener port. The listener port uses the information in the CCDT when it performs the reconnection attempts.

If the listener port tries all of the entries in the CCDT and is still unable to connect to the queue manager, then the port waits for the period of time specified by the RECOVERY.RETRY.INTERVAL property before trying again.

The message listener service property MAX.RECOVERY.RETRIES defines the number of consecutive reconnection attempts that are made before a listener port stops and requires a manual restart.

Once the listener port has reconnected to an IBM MQ system, the Java EE environment performs any transactional cleanup that is required, and then resumes delivering messages to MDBs for processing.

In order for the transactional cleanup to work correctly, the Java EE environment must be able to access the logs for the queue manager that failed.

If the listener ports are being used with transactional MDBs that participate in XA transactions, and are connecting to a multi-instance queue manager, the CCDT must contain an entry for both the active and standby queue manager instance.

This means that the Java EE environment can access the queue manager logs if the environment needs to perform transaction recovery, regardless of which queue manager the environment reconnects to following a failure.

If the transactional MDBs are being used with stand-alone queue managers, the CCDT must contain a single entry, to ensure that the listener port always reconnects to the same queue manager running on the same system following a failure.

Ensure that we have set the default value of PREFERRED for the AFFINITY property on the CCDTs, used with listener ports, so that connections are made to the same active queue manager.

CLIENTRECONNECTOPTIONS property

Listener ports provide their own reconnection functionality. The provided functionality allows the listener ports to automatically reconnect to an IBM MQ system if the queue manager they were connected to fails.

Because of this, the automatic client reconnection functionality provided by the IBM MQ classes for JMS is not supported.

We must set the CLIENTRECONNECTOPTIONS property to DISABLED for all listener ports that are used in the Java EE.