Fuzzy JMS Tuning for WSO2 APIM MI and Azure Service Bus

There are three phases to this one: 

Phase 1 – Enhance Your Logging

First you’ll want to add the some of the JMS_* fields to your logging to aid in debugging. I suggest at a minimum you add these two and then log them:

•      <property expression=”$trp:JMSXDeliveryCount” name=”JMS-X-Delivery-Count”/>
  
•      <property expression=”$trp:JMS_MESSAGE_ID” name=”JMS-MESSAGE-ID”/>

Phase 2 – Surpress QPID Buffer and Apply JMS Tuning

This is especially critical if you having servers that are running out of memory from getting too much data all at once. 

Second phase to be done if in the first you find that you are reprocessing the same message multiple times and it still goes to the DLQ. Upgrade QPID to at least version 1.6 and then add these parameters to your jndi connection string. It will tell QPID client to not grab a bunch of messages from ASB in its buffer and instead will allow WSO2 to control when it gets messages. Add this setting in your jndi.properties file in the connection for ASB: jms.prefecthPolicy.all=0&Provider.futureType=balanced. (This needs to be added after the question mark in the uri.)

Next you’ll want to review these best practices and tuning guides:

• JMS Parameters
• Tuning the JMS Transport
• Tuning Network and OS Performance
• Tuning JVM Performance

 If you are using EI 6.6.0 please also look into adding proxy-level-throttling.

Please note: Do not upgrade QPID to version 2.0 because there are breaking changes that are not yet compatible.

Phase 3 – Adjust ASB Settings

And the third thing you can do is change your Topic Subscriber, or Queue, Message Lock Duration from the default of 30 seconds to something longer like 2 or 5 minutes in the Azure Portal. Also look at changing the max delivery count from say 5 to something like 10 or 15.