AbstractPollingMessageListenerContainer's workaround for Tibco causes performance delays during ems failover [SPR-14697]

[spring-projects-issues]

Aihua Zhou opened SPR-14697 and commented

We're using DefaultMessageListenerContainer with tibco EMS and transaction enabled,

when ems fails over, and there is no messages on ems, then we observer the following behavior:

1. If there are no messages on EMS during failover, and we publish a message well after all clients have reconnected, then the client will still throws TransactionRolledbackException, due to the fact that the polling container does not commit the transaction if it receives no message if it's using Tibco EMS.

2. This is a problem for high concurrency systesm, where we're running over 100 clients. In this case each client is holding on to a transaction which will be rolled back. With queue redelivery set to mas of 255 and delivery delay set to 15, it takes over 1 hour for the messages to get reprocessed.

The issue is caused by the work around that was put in place for a tibco deadlock issue See spring jira below.

#12215

Tibco has confirmed that the deadlock issue was fixed in ems 4.4.2, and is no longer present in any supported versions of ems. Please roll back the special check that was added.

---

Affects: 4.1.9, 4.2.4, 4.3.2

Issue Links:

• JMS integration with Tibco causes deadlock due to commitIfNecessary in AbstractPollingMessageListenerContainer [SPR-7558] #12215 JMS integration with Tibco causes deadlock due to commitIfNecessary in AbstractPollingMessageListenerContainer

Referenced from: commits edbc1e9, 4396b21, 53fc1e9

Backported to: 4.2.8

[spring-projects-issues]

Juergen Hoeller commented

Fixed in master, and to be backported to our 4.3.3 and 4.2.8 releases next week.