SAG fixes for jms connections using JNDI.

High CPU on mainframe associated with MQ processes.

The issue seems to be with the connections using ESB_NO_TXN_02 to queues:
MQQ_PUB_V1
MQQ_PUB_V2 (superceded by V3)
All of the triggers for these queues have 50 threads. I have looked at the current time that it takes to process the interfaces using these queues. If the processing time is fast enough then we may be able to reduce the number of threads.
This might mitigate the problem
We could also look at adjusting these extended settings:
watt.server.jms.trigger.concurrent.consecutiveMessageThreshold=10 watt.server.jms.trigger.concurrent.primaryThread.pollingInterval=1000 watt.server.jms.trigger.concurrent.secondaryThread.pollingInterval=12

If we can map the services used in these interfaces then we can check the current performance, and look to reduce the threads. 50 threads is a lot. That’s up to 200 threads across all 4 servers!
Have looked in some high volume interface, so I think we can reduce the threads from 50 to 20 for some interface.
Can more analysis needed to see if reducing the threads will still meet the NFRs.

Your inputs and thought suggestions for this can help

Hi Istkhar,

please check for latest Fixes for Broker Core and Broker Java API (contains JMS API as well) for your Broker version.

Regards,
Holger