Starting a "cold" listener container

[keenan]

I could use a recommendation for working around a problem that arises when we try to start a listener container that has been stopped for a long time (ex: hours).

Here is the stack trace:

[2008-10-15 01:16:04,654] [GC.GTP.#1] [WARN ] [(null)] [(null)] [AbstractListenerContainer] Ignoring Connection start exception - assuming already started
Apache.NMS.ActiveMQ.ConnectionClosedException: The connection is already closed!
   at Apache.NMS.ActiveMQ.Connection.CheckConnected() in c:\code\3rdparty\apache\activemq\nms\trunk\src\main\csharp\Connection.cs:line 400
   at Apache.NMS.ActiveMQ.Connection.Start() in c:\code\3rdparty\apache\activemq\nms\trunk\src\main\csharp\Connection.cs:line 114
   at Spring.Messaging.Nms.Connections.CloseSupressingConnection.Start() in c:\code\3rdparty\spring.net\trunk\src\Spring\Spring.Messaging.Nms\Messaging\Nms\Connections\SingleConnectionFactory.cs:line 489
   at Spring.Messaging.Nms.Listener.AbstractListenerContainer.StartSharedConnection() in c:\code\3rdparty\spring.net\trunk\src\Spring\Spring.Messaging.Nms\Messaging\Nms\Listener\AbstractListenerContainer.cs:line 496

I'm still looking into why the connection gets closed (NMS 1.1 has a "keepalive" feature so technically the connection should not get dropped even when we stop accepting messages for awhile) but in the meantime is there any way to get the listener stared when this happens?

[Mark Pollack]

Hi,

This looks like a bug/issue at least in Spring's code in part. The Java code catches javax.jms.IllegalStateException (an exception that doesn't exist in the NMS API) and we catch all exceptions, not a good idea for sure. At the moment, a workaround is to subclass the container and override StartSharedConnection and then you can set the custom container type in the nms namespace with the element container-custom-type. I'll look a bit deeper into the exceptions thrown out of NMS Connection.Start() and see what should be done. Thanks for reporting this.

Cheers,
Mark

[keenan]

Great, that will work fine.

I found another corner case. If we shut down the AMQ broker, the listener container (correctly) executes the OnException() method and then attempts to reconnect. Immediately before this happens, the code in SimpleMessageListenerContainer.cs is:

                lock (consumersMonitor)
                {
                    sessions = null;
                    consumers = null;
                }

If we then stop our service, which calls ContextRegistry.Clear(), the listener container ends up in the DoShutdown() method, which has this code:

            foreach (IMessageConsumer messageConsumer in consumers)
            {
                NmsUtils.CloseMessageConsumer(messageConsumer);
            }

However, consumers is null due to the first code snippet so the result is:

System.NullReferenceException: Object reference not set to an instance of an object.

I assume the fix is simply to check for null on the consumers and sessions properties before iteration.

[Mark Pollack]

Hi,
Thanks once again! Fixed and recorded as SPRNET-1070.
Mark

[Mark Pollack]

Hi,
Regarding the error in the initial post

[2008-10-15 01:16:04,654] [GC.GTP.#1] [WARN ] [(null)] [(null)] [AbstractListenerContainer] Ignoring Connection start exception - assuming already started
Apache.NMS.ActiveMQ.ConnectionClosedException: The connection is already closed!
   at Apache.NMS.ActiveMQ.Connection.CheckConnected() in c:\code\3rdparty\apache\activemq\nms\trunk\src\main\csharp\Connection.cs:line 400
   at Apache.NMS.ActiveMQ.Connection.Start() in c:\code\3rdparty\apache\activemq\nms\trunk\src\main\csharp\Connection.cs:line 114
   at Spring.Messaging.Nms.Connections.CloseSupressingConnection.Start() in c:\code\3rdparty\spring.net\trunk\src\Spring\Spring.Messaging.Nms\Messaging\Nms\Connections\SingleConnectionFactory.cs:line 489
   at Spring.Messaging.Nms.Listener.AbstractListenerContainer.StartSharedConnection() in c:\code\3rdparty\spring.net\trunk\src\Spring\Spring.Messaging.Nms\Messaging\Nms\Listener\AbstractListenerContainer.cs:line 496

What connection factory were you using? I suspect it was SingleConnectionFactory or a subclass. Can you set the property ReconnectOnException on SingleConnectionFactory to true, this will reset the state of SingleConnectionFactory and it will create a new Connection when asked in future API calls.

Cheers,
Mark

[keenan]

Thanks for the reminder. I had that property set on some of my sample code but I forgot about it and neglected to migrate it to the real application.