MockQueue not threadsafe
Brought to you by:
aibba
Menu
▾
▴
I just started using Mockrunner to test my JMS app. I have multiple threads reading from a request queue, and it appears that MockQueue is not threadsafe. Each thread is using the Spring JmsTemplate to look for messages, so there are sessions being created continually. When you try to send a message to the queue, it gets a ConcurrentModificationException in MockQueue.addMessage(), because the sessions set is being modified (by another thread) while it is iterating over it. Would it be possible to have threadsafe versions of MockQueue and MockDestination for use in multi-threaded scenarios? It should be possible just to synchronize all access to the sessions set.
Also, I get a huge memory leak because each new session gets added into the queue's session set, but never removed. Can't the session remove itself from any destinations it has been added to when it is closed?
Colin Sharples
Wellington, New Zealand.
Hi Colin,
The JMS implementation is not thread-safe. This is also stated on the JMS example page (last sentence). It is designed for simple single-threaded unit tests. Making JMS (and the rest of Mockrunner) thread-safe is on my todo-list but unfortunately it's a very long list :-) I'll stay away from synchronizing some parts of JMS with the hope that everything works fine. I think it's some work to get the whole framework thread-safe (including proper tests for this feature). You may want to do your own research on this topic but I'll not release a multithreaded version until I'm really sure that everything works fine (backed by unit tests).
As for your memory leak: The session cannot remove itself because it is still accessed by Mockrunner even it is closed (you may want to test that a session existed and what happened to the session during its lifetime). You should not get a memory leak if you rebind your queue in every setup method. Mockrunner does inititialize the MockJNDI implementation in every setup anyway so everything gets evicted. The mock queues are meant to exist for one single test method.
Kind regards,
Alwin
I just had a look at the current implementation. I guess it would be easy to refactor it so that the destination doesn't need references to all (open and closed) sessions. I think you are right, it's better to clean up closed sessions and remove them from destinations. I'll refactor that for the next release.
Regards,
Alwin
Hi there,
I am also having the ConcurrentModificationException in MockQueue.addMessage() because of multi threaded message sending in my unit tests.
Is there any chance you can move this issue up a notch in your to-do list? It would be great if you could fix it in the next realese.
I have version 0.3.1 (maven artifact) of mockrunner.