Announcement Announcement Module
Collapse
No announcement yet.
22/Oct/2012 15:34:52:015 WARN - DefaultMessageListenerContainer.handleListenerSetu pF Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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
    Last edited by aug828; Oct 22nd, 2012, 03:35 PM.

  • #2
    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.

    Comment


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

      Comment


      • #4
        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).

        Comment


        • #5
          Thanks.

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

          Comment


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

            Comment

            Working...
            X