JMS -SimpleMessageListenerContainer Vs DefaultMessageListenerContainer

Spring provides a JMS integration framework that simplifies the use of the JMS API. Message Listener is part of the JMS applications. In order to asynchronously receive JMS messages, Spring offers a solution to create message-driven POJOs (MDP).

Spring MessageListenerContainer allows us to register MessageListeners without an EJB container. It is used to receive messages asynchronously. It is the intermediary between a Pojo and a messaging provider. It polls the message from the Queue and feeds it to the listener.

The two standard JMS MessageListenerContainer packaged with Spring are : DefaultMessageListenerContainer (DMLC)and SimpleMessageListenerContainer (SMLC)

The details and methods of both containers can be checked here. I specifically am going to write about the differences and the issues faced while creating a JMS application.

While SimpleMessageListenerContainer uses a push approach, DefaultMessageListenerContainer on the other hand uses a pull approach which essentially means it sits in an infinite loop to receive messages.

SMLC is the simplest form of a message listener container. It creates fixed number of JMS Sessions to invoke the listener and does not allow any runtime demands. Its main advantage is its low level of complexity and the minimum requirements on the JMS provider.

While SMLC is simple to use and is preferred for native JMS and if the JMS provider handles thread management and connection recovery gracefully,It has some disadvantages as well .

Especially in case where your Queue/Topic is not hosted on the same server as your listener or there is frequent connection failures to the JMS provider, thread management will be the main problem in SMLC as it goes on creating unnecessary threads as soon as your listener is started and thread count goes beyond the ulimit for that server, As Linux has a maximum allowed process per user limit,this might result in application giving error (unable to create new native thread: out of memory issue).

You would require to restart your application to kill all the threads which will deviate from the whole purpose of continuous listening of messages using MessageListenerContainer.

The solution for the above-described issue is DMLC should be used in such cases and is also a more recommendable approach in many environments. It does not use/block JMS provider threads. It also handles connection failures gracefully.

To dive a little deep, I had an application with JMS implementation. Initially, with SMLC it was working fine till the time the JMS provider was hosted on the local server.

The later provider was moved to AWS setup and had some usual connection resets, which started causing the thread issue. This issue was resolved after I replaced my SimpleMessageListenerContainer with DefaultMessageListenerContainer.

In this article, we took a look at two different JMS listeners that Spring offers and their usage. I hope you found it useful.

Thanks!