DefaultMEssageListenerContainer Auto Reconnect with JBOSS MESSAGING 1.4.0

[vishnudeep]

Hi,

I am using DefaultMEssageListenerContainer with JBOSS MEssaging.

When my JMS Server is stopped and restarted, it is not able to reconnect.


Can anyone help me?? Any Ideas??

[vishnudeep]

more details..


I implemented messaging through Spring Remoting JMS asynchronously by defining interfaces and implementing them ( as described in the blog using lingo)http://www.jroller.com/sjivan/entry/...allbacks_using

In the configuration files i am using DefaultMessageListenerContainer as listener.

I am using JBOSS -MESSAGING 1.4.0 CRT

WHat i need is , i am not able to reconnect if the messaging server comes up after a crash.

Let me know, if you guys have any ideas.

One more thing is i am using sessionTransacted = true,

Although in the JMS Spring remoting implementation interface i am throwing runtime exception intentionally, the message is not getting redelivered.

How can i handle transactions, i tried all the possible cases from documentation, but no help.
I need message redelivery if any exception occurs.

Any help is appreciated.

[Juergen Hoeller]

DefaultMessageListenerContainer should recover from connection failures automatically. What is the exact behavior that you're seeing at runtime? Try activating the debug log for DefaultMessageListenerContainer and see what it actually does when your message broker goes down...

Juergen

[nkhadakk]

JBoss AS 4.2.2/JBoss Messaging 1.4SP1/Spring 2.0.7

I am seeing a similar issue with DMLC when i have the following configuration :

<bean id="URIListener" class="com.getmedium.services.messaging.MessageContainer" depends-on="ResolvedURIQueue" destroy-method="shutDown" > 
	   <property name="concurrentConsumers" value="${com.getmedium.medium.messaging.urimessaging.listener_count}" />
	   <property name="connectionFactory" ref="ListenerConnectionFactory" />
       <property name="destination" ref="ResolvedURIQueue" />
       <property name="messageListener" ref="uriEventMessageListener" />
	   <property name="taskExecutor" ref="taskExecutor" />
	   <property name="exceptionListener" ref="excListener" />
	   <property name="cacheLevel">
			<util:constant static-field="org.springframework.jms.listener.DefaultMessageListenerContainer.CACHE_CONSUMER"/>   
	   </property>
	   <property name="recoveryInterval" value="${com.getmedium.medium.messaging.urimessaging.listener_reattach_interval}"/>
    </bean>

When i set the Cache level to 'CONSUMER', my exception listener is NEVER invoked if the JMS provider goes down. Also after the JMS provider comes up ... my DMLC is left listening at a old port/socket and never gets any new messages.
If i change the cache level to 'SESSION', all the DMLC recovery mechanisms work like a charm.
Of course the side affect of not caching Consumers is that consumers are created for every 'receive poll' on the Provider side.

What is the usecase for using CONSUMER level caching Versus SESSION caching ?
Why does the CONSUMER caching level cause Exception Listener to be bypassed ?

[denis.zhdanov]

Your configuration snippet shows that you use some custom class (com.getmedium.services.messaging.MessageContainer ) and experience some problems with it. Do you really think that telepathic skills of forum members are good enough to point out the reason of your problem?

I use standard DMLC with default cache level (CACHE_CONSUMER) and recovery works fine.

[nkhadakk]

Below is my code for the 'custom' DMLC. This DMLC is customized to allow for debugging purposes only and does not add any functional value to the default DMLC.
I inadvertantly forgot to add the code snippet.

Does anybody have an idea of standard best practice for using different cache levels (SESSION vs CONSUMER) ? Does the server config dictate which one to use ?

public class MessageContainer extends DefaultMessageListenerContainer
{
    private static final Logger _logger  = Logger.getLogger( MessageContainer.class);
    protected void executeListener(Session session, Message message) {
        try {
            super.executeListener(session, message);
        }
        catch (Throwable ex) {
            super.handleListenerException(ex);
        }
    }
    public void shutDown()
    {
        _logger.info( "************ Shutting down Thread Pool *************");
        super.shutdown();
    }
}

Denis, in an effort to maintain professionalism in these communications i will assume that you don't realize that your 'post'(or flame) is in poor taste and attacks at a personal level as opposed to the problem at hand.