Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

JMS MDB listerner shows multiple running instance in SMA



In System Management Application (SMA) user is seeing multiple running instances for JMS listeners.

User does not see any functional impact any held up message is re-queued and processed. Observed in past that this is a additional instance created after every WAS restart, which is generally done after any failure or major change.
One does not see any exceptions in log files and requires to know the reason for creation of these sleeping listeners and remove them.

Error Messages

Getting multiple running instance of IAS listeners.

Steps to Reproduce

Step 1: Open SMA.
Step 2: Click on any node.
Step 3: Click on Listener management.
Step 4: Search for running instance of IASInboundJMSListener & IASInboundJMSListenerFPS lsiteners.

Root Cause

The requestor is returned to the pool or passivated, XA or non-XA. But with XA, depending on the value of the “Maximum failed deliveries per message” configured for this destination, the message that caused a failure gets re-delivered multiple times causing more requestors from the requestor pool get activated before they get destroyed.
The things to check and to tune are:
  1. “Maximum failed deliveries per message” parameter configured in the WAS Admin Console for this destination.
  2. The service package is configuration for the service this listener invokes: (is it stateless or stateful, does it require authentication?) More important, the size of the requestor pool for this package (maximum idle requestors and maximum active requestors).
  3. Also a system cleaner agent that removes all the passivated requestors.

There is very little one can do in this case since this is moderated outside PRPC. WAS takes the lead to bump up the requestors. 


The  issue is mainly caused the requestor handling in WebSphere Application Server. However Pega found one WebSphere configuration that can reduce the JMSMDB list in SMA when a message delivering failure occurs.

1) Access Buses

2) Select your Bus

3) Select the Destinations

4) Select the Queue

5) Change Maximum failed deliveries per message value to 1

6) Restart the server

Prior to this configuration, when a JMS Message process fails, user can see ten listener instances in SMA. 
After the changes are done to the above Websphere setting, only one instance per message failure is seen.

Unfortunately, this does not completely resolve the issue, but the proposed configuration does reduce the JMSMDB listener list which user might consider applying it in the environment.



Published January 31, 2016 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us