Understanding JMS integration testing with Spring

Question

Please some help understanding the following:

I am using CachingConnectionFactory in my app and first used it during my jms tests to test my jms config like guaranteed delivery, rollback/commit, etc..

I am using Spring's JmsTemplate for sending and DefaultMessageListenerContainer during delivery.

1. I noticed that this is hard/impossible when using several test methods run sequential Example: in test method A I throw exceptions in the Message listener (consumer side) such that retries occur. Then test B is run and in method A I do a different test, but when I start this test I still get retry messages from test A, which I clearly not want. I purge the Queue through jmx between tests, but still receive these retries :(... I searched and debugged... I don't exactly understand why these retries keep comming up, even when I am sure that the purge occur correctly. Maybe it was already cached somewhere in the session... I don't know. Anybody any idea?

2. I found out that I needed to use the SingleConnectionFactory during testing. With this connection factory the retries disappear, but I don't really understand why. Why? I understand that it uses only one connection (from the Spring ref), and noticed that it somehow removes the consumer after every send action, but I don't really understand what happen with these retries :(... Any idea? (It's hard to debug because of the multi threading behavior and difficult to find good information about it on the web) Also using CachingConnectionFactory with only one session cache size of 1 didn't solve the retry issue.

Thanks

Answer 1

It's not an easy thing to fix: remove the messages between tests. I tried many thingssss, like mentioned above: stop/start the broker and the class DefaultMessageListenerContainer of Spring that I use to consume my messages. It all seem to work until I turned I set the cache level in DefaultMessageListenerContainer to Consumer such that the consumer is cached. That is required such that the redeliveryPolicy works. However, this messed up everything and messages where cached by DefaultMessageListenerContainer in some way, as it seemed.

At the end, I solved it by simple consuming all messages after a test (just wait a second and consume all Ok), such that the next test can begin.

Answer 2

Best bet would probably to use an embedded broker and start/stop it between each test, make sure deleteAllMessagesOnStartup is set to true and the broker should purge the store fore you, which will ensure you've got a clean slate for each test. You might also benefit from having a look at ActiveMQ's unit tests, it's a good source of examples of how the broker can be used in automated tests.