22/Oct/2012 15:34:52:015 WARN - DefaultMessageListenerContainer.handleListenerSetu pF

[aug828]

We got this in the log file every 5 seconds(exactly 5 seconds).
What could be the reason? Is this a bug? Fixed?

BTW, we are using spring 3.0.5.

<jms:listener-container
container-class="org.springframework.jms.listener.DefaultMes sageListenerContainer"
connection-factory="***ConnFactory" acknowledge="transacted"
concurrency="5">
<jms:listener destination="***QueueName" ref="***QueueListener" />
</jms:listener-container>

22/Oct/2012 15:34:52:015 WARN - DefaultMessageListenerContainer.handleListenerSetu pFailure - Setup of JMS message listener invoker failed for destination '******' - trying to recover. Cause: Connection is closed

[Gary Russell]

5 seconds is the default delay between connection recovery attempts (setRecoveryInterval).

It means the container lost connection to the broker and cannot reconnect.

What are you using for a ConnectionFactory? What is the DMLC caching level?

The Spring connection factories detect JMX Exceptions (via an ExceptionListener) and reestablish the connections as needed.

Running with DEBUG logging level will add a full stack trace to the 'Connection is Closed' exception.

DEBUG logging should also provide some indication of what is going on during connection recovery.

[aug828]

I didn't set up the DMLC caching level.
Would this lead to any issue?

[Gary Russell]

Not really; it defaults to NONE if there is an external transaction manager, or CACHE_CONSUMER otherwise.

In either case, if the connection is broken, the DMLC gets a connection from the factory. The factory is responsible for creating the connection (or refreshing a dead cached connection).

[aug828]

Thanks.

What if the problem won't reproduce, after I set the logging level to DEBUG?
Does that mean it's a network issue?

[Gary Russell]

That's probably a reasonable assumption, or the broker itself was down.