MessageListenerAdapter and invalid ReplyTo destination

[batalbot]

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 
    {
        try
        {
            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() );
                return;
            }
            throw e;
        }
    }

Thanks for any help

-Bryan

[nkhadakk]

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.

[batalbot]

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.