Product : Integration server 10.11 Core Fix 1
component : JMS Trigger with Solace

We are trying to implement Transacted JMS Trigger [ XA Transaction ] with Solace Event Broker. Since we are using Transacted JMS we do not have parameter to set the the retry limit and time between the retry as we have for non transacted JMS

Non Transacted Properties :
Max retry attempt
Retry Interval **
On Retry failure

Transacted JMS Trigger Properties :

On Transaction Roll back : suspend and recover

Hence we are relaying on the below as per the webMethods JMS developer Guide to use the below are the run time parameter of server :

**watt.server.jms.trigger.maxDeliveryCount 5 **
watt.server.jms.connection.retryPeriod 60

We trying to mock the trigger service to failure with throw transient error by mocking endpoint [ com.wm.app.b2b.server.ISRuntimeException ]. But maxDeliverycount or retryPeriod is not honoring and service goes into closed circuit and keep processing .

Any thought/ suggestion welcomed

Dear @DINESH_J

From the documentation - The “watt.server.jms.trigger.maxDeliveryCount” property specifies the maximum number of times the JMS provider can deliver a message to Integration Server. The default is 100. Integration Server enforces a maximum delivery count, which determines the maximum number of time the JMS provider can deliver the message to the JMS trigger.If the maximum delivery count has been met, the JMS provider will not deliver the message to the JMS trigger. Instead, the JMS provider will acknowledge and remove the message. The maximum delivery count is controlled by the watt.server.jms.trigger.maxDeliveryCount property.

I believe this property signifies the maximum number of times any message can be redelivered to the trigger.

From the documentation (transacted JMS trigger) - Because a transaction is an all or nothing situation, a trigger service cannot retry a message if a trigger service ends because of a transient error. Designer does not display the retry properties (Max retry attempts, Retry interval, and On retry failure) for a transacted JMS trigger.

I would suggest, if you really do not have an XA Transaction requirement, go ahead with a Non-Transacted JMS trigger. XA Transactions should be considers only when you need to handle a transaction spawning different resources (eg: JMS with JDBC ) . If you are working with only one JMS provider then Non-Transacted JMS trigger can provide you with “Retry” with “Message Recovery”

On the trigger set as follows for “Transient Error handling”
Max retry attempt - 2
Retry Interval - 10 seconds
On Retry failure - Suspend and retry later

The logs of the trigger shows reattempts and the message is rollbacked to the JMS provider

2023-01-16 12:10:59 GST [ISS.0134.0066I] JMS trigger MY_Sample_Flow.solaceMessaging:NoTXSolaceReceiveJMSMessage has started 
2023-01-16 12:11:00 GST [ISP.0090.0003C] ****Attempting to read message  0 times***  
2023-01-16 12:11:00 GST [ISP.0090.0003C] *****Catch Block is executed on  Error - **** %jsonString% 
2023-01-16 12:11:11 GST [ISP.0090.0003C] ****Attempting to read message  1 times***  
2023-01-16 12:11:11 GST [ISP.0090.0003C] *****Catch Block is executed on  Error - **** %jsonString% 
2023-01-16 12:11:22 GST [ISP.0090.0003C] ****Attempting to read message  2 times***  
2023-01-16 12:11:22 GST [ISP.0090.0003C] *****Catch Block is executed on  Error - **** %jsonString% 
2023-01-16 12:11:22 GST [ISS.0134.0042E] JMS Trigger MY_Sample_Flow.solaceMessaging:NoTXSolaceReceiveJMSMessage failed: com.wm.app.b2b.server.ISRuntimeException: *******Throwing a retry Exception**** 
2023-01-16 12:11:22 GST [ISS.0134.0068I] JMS trigger MY_Sample_Flow.solaceMessaging:NoTXSolaceReceiveJMSMessage has been suspended 
2023-01-16 12:11:22 GST [ISS.0134.0046E] JMS Trigger MY_Sample_Flow.solaceMessaging:NoTXSolaceReceiveJMSMessage **has recovered the message(s)**. 

Let me know if this helps.

Best Regards,
Franklin