Spring DefaultMessageListenerContainer - listener does not read messages on Websphere MQ

Question

I am using Spring 3.0 - DefaultMessageListenerContainer to connect to WebSphere 6 MQ. MQ already has messages. When I run my test, the listener that implements the SessionAwareMessageListener starts. But onMessage () does not call. Thus, the problem is that messages already in the queue are not read.

According to docs, autoStartup is true by default (and I haven't changed it). In accordance with my underutilization, at startup, the listener should read the queue for any existing messages, and the onMessage () function should be called. Please let me know if this understanding is incorrect.

Here is a snippet from the configuration file:

<bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="jmsQueueConnectionFactory" /> <property name="destinationName"> <value>${queue}</value> </property> <property name="messageListener" ref="exampleMessageListener" /> <property name="concurrentConsumers" value="1" /> <property name="maxConcurrentConsumers" value="1" /> <property name="idleTaskExecutionLimit" value="4" /> <property name="maxMessagesPerTask" value="4" /> <property name="receiveTimeout" value="5000" /> <property name="recoveryInterval" value="5000" /> <property name="sessionTransacted" value="true" /> <property name="transactionManager" ref="jmsTransActionManager" /> </bean> 

Note: there is no error / exception, the test application starts just fine.

Any pointers to solve this problem will be helpful.

Thanks,
Rj

Answer 1

The problem is resolved. The testing class ended after the listener received the message, but before he could display the message as output. Thus, the first message (with the highest priority) was lost from the queue.

Later, when I turned on the transaction manager, the listener put the message back in the queue (it shows a warning as Rejecting a received message from the listener's container when it was stopped at the same time). Since this was a warning, and my logger was at the debug level, I skipped this earlier.

Entering Thread.sleep in the test class made sure that it works for a long time, and the listener could read all the messages in the queue in priority order :)

amuses
Rj

Answer 2

This is not an answer in fact, but I do not want to create a new question for the same problem.

I initialized Spring context

 ctx = new ClassPathXmlApplicationContext("classpath:" + args[0]); 

read the configuration and then call (due to a warning that the source was not closed):

 ctx.stop(); 

and I didn’t understand that it will stop my beans, after one day of debugging I found this message in the log

 DEBUG oscsDefaultLifecycleProcessor - Asking bean 'messageListenerContainer' of type [class org.springframework.jms.listener.DefaultMessageListenerContainer] to stop