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.
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.
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:
- “Maximum failed deliveries per message” parameter configured in the WAS Admin Console for this destination.
- 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).
- 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.
0% found this useful