Announcement Announcement Module
No announcement yet.
MessageListenerAdapter and invalid ReplyTo destination Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • MessageListenerAdapter and invalid ReplyTo destination

    I have a stand-alone process (no J2EE container) listening on a queue and sending response messages to the destination in the ReplyTo header. The application is configured to use spring's MessageListenerAdapter and DefaultMessageListenerContainer.

    Everything works fine until a message is received that has an invalid destination in the ReplyTo header. In my use case, the requester has disconnected (timeout) and the temporary destination created for a reply has been closed by the broker (SwiftMQ).

    When this happens, the MessageListenerAdapter throws the JMSException back to the DefaultMessageListenerContainer which attempts to redeliver the problem message again -- this continues indefinitely.

    This seems like a common use case. What is the best way to handle this condition?

    I have a work-around but it is certainly not pretty. My work around involves sub-classing the MessageListenerAdapter and overriding the sendResponse() method to check for certain JMSExceptions. Unfortunately it looks like I have to check the exception's message string to see if it's an exception that should be ignored.

        protected void sendResponse( Session session, Destination destination, Message response ) 
            throws JMSException 
                super.sendResponse( session, destination, response );
            catch( JMSException e )
                if( e.getMessage().matches( "com.swiftmq.swiftlet.queue.UnknownQueueException: queue 'tmp\\$[^']+' is unknown" ) )
                    logger.warn( "Discarding response message - " + e.getMessage() );
                throw e;
    Thanks for any help


  • #2
    I haven't worked with SwiftMQ, but is there some sort of setting on the JMS Provider for 'maxNumberOfRedeliverys' ? Also at more of a coarse grained level, you can set the Message.setJMSRedelivered(boolean) to false to preclude any redelivery (not very useful, but an option i guess) of a Message.


    • #3
      It turns out there's a bug in SwiftMQ that causes it to not throw an InvalidDestinationException and to throw a plain JMSException instead. This bug forces the check of the message content, but even if the proper exception is thrown, I'm still forced to over ride a spring class to get what I thought was supported functionality of the request-response pattern.

      I would still like to know what the best practice is for this pattern in dealing with requests whose destination is no longer valid. If sub-classing is required, that seems to eliminate the use of the jms xml-namespace as well in an application context as well.