Losing JMS messages with ActiveMQ failover connections in case of a shared SingleConnectionFactory [SPR-4971]

[spring-projects-issues]

Kirill Petrov opened SPR-4971 and commented

If DefaultMessageListenerContainer is set to be transactioned and when it is using ActiveMQ failover connection DefaultMessageListenerContainer might lose a message if ActievMQ goes down.

---

Affects: 2.5.5

Attachments:

• activemq.xml (5.12 kB)
• jmstransaction.tar.gz (8.28 kB)

[spring-projects-issues]

Kirill Petrov commented

I am attaching a junit test that does the following, it sends 10 jobs to a queue1 and then consumes those jobs from queue1 and sends them to queue2 in a transaction. I expect exactly 10 messages in queue2 after execution of this junit. I test transactional integrity by killing activemq right after I receive a message. I expect that when activemq goes up, and I call commit, an exception is thrown (since activemq is not aware of the transaction). After that the message should be redelivered.

Currently, junit illustrates two (2) scenarios:
(1) first scenario when Spring and DefaultMessageListenerContainer is not used. This method is commented out, its name is testTransaction() in class FailOverTransactionTest. It shows that if I restart activemq during this test execution transactional integrity is preserved and I receive exactly 10 messages in queue2.
(2) second scenario uses DefaultMessageListenerContainer, SingleConnectionFactory, and JmsTemplate. If I restart activemq, during junit execution I will lose as many messages as many times I restart ActiveMQ. So, if one restarts ActiveMQ once after the prompt "Freezing for 10 seconds, please restart ActiveMQ", he will get only 9 messages in queue2.

I suppose this happens because of some kind of caching, though I did not dig deep enough in Spring code. I don't mind to fix this issue but I want it to be verified by the Spring team first.

thanks,

Kirill

[spring-projects-issues]

Kirill Petrov commented

This is activemq configuration file that I use. It should not really matter but I included it just in case.

[spring-projects-issues]

Juergen Hoeller commented

Spring doesn't actually perform any caching there... It relies entirely on the JMS Session to behave appropriately.

Does it make a difference if you configure the DefaultMessageListenerContainer with the raw ActiveMQ ConnectionFactory rather than with the SingleConnectionFactory wrapper? Generally, DMLC manages its own shared Connection anyway, so there's no real need to configure it with a SingleConnectionFactory - unless you want to share the very same JMS Connection across multiple DMLC instances.

Juergen

[spring-projects-issues]

Kirill Petrov commented

I will try to use raw ActiveMQ ConnectionFactory and see how it goes.

[spring-projects-issues]

Kirill Petrov commented

I used raw ActiveMQ Connection factory instead of SingleConnectionFactory and everything worked properly. So, it is a problem with SingleConnectionFactory wrapper?
I indeed prefer to use the same connection across multiple DMLC's. I can not set a connection directly neither on JmsTemplate nor on DMLC. Does it basically mean that each DMLC should get its own connection?

[spring-projects-issues]

Juergen Hoeller commented

In general, each DMLC expects to have its own Connection, allowing for individual stopping/restarting as well as for individual recovery. It is strange, though, that SingleConnectionFactory loses messages in your scenario. There is nothing special that SingleConnectionFactory does really, so I suppose the actual problem is in ActiveMQ's Connection implementation...

In any case, for the time being, I would recommend using a dedicated Connection per DMLC instance.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

I'll close this from Spring's side for the time being, since the recommendation is to let each DMLC instance manage its own JMS Connection. Using SingleConnectionFactory is considered advanced in a message listener container scenario: i.e. it may or may not work properly, depending on the message broker and JMS driver in use.

Juergen