Process is terminated due to StackOverflowException

[keenan]

I'm not 100% sure this is a Spring.NET problem, but I wanted to document it here just in case.

We have a command line server which aborts with a StackOverflowException, usually within a few minutes after AMQ is shut down.

I will try to put together a small test case, but basically what we have are classes that read and write to queues (fairly low volume-- 100 messages or less).

If I shut down AMQ, I expect to see errors in the log from the producers and consumers, and indeed the stack traces are logged which indicate that communication with AMQ failed, such as:


System.Exception: Error writing to broker. Transport connection is closed.
at Apache.NMS.ActiveMQ.Transport.Tcp.TcpTransport.One way(Command command)


However, about 1-5 minutes later our server shuts down and the following is printed to the console:


Process is terminated due to StackOverflowException.


I wouldn't expect to get that just because AMQ is offline.

The producers are using a shared NmsTemplate instance and the consumers are using SimpleMessageListenerContainer and MessageListenerAdapter from the Spring.Messaging.Nms assembly.

Any ideas?

[Mark Pollack]

Hi,

I don't have any ideas and a quick search through JIRA/newsgroups didn't turn up anything outstanding. There is this issue (https://issues.apache.org/activemq/browse/AMQNET-102), with a similar symptom. The svn revision used in the M1 release includes that fix, so that isn't the cause. Can you determine where the stack overflow is occuring by setting a breakpoint.

If you could package up a simple test case, that would help me diagnose the issue to see if it is activemq related or spring related. Even better would be a pure nms api based test case...:)

Cheers,
Mark

[keenan]

If you could package up a simple test case, that would help me diagnose the issue to see if it is activemq related or spring related. Even better would be a pure nms api based test case...:)


I'll try to put together something tonight, but in the meantime I did turn on Spring.NET logging at the debug level and before the stack overflow the log has several megabytes worth of these lines:


[2008-08-25 15:16:41,879] [20] [DEBUG] [(null)] [(null)] [TransactionSynchronizationManager] Retrieved value [Spring.Messaging.Nms.Listener.LocallyExposedNmsRes ourceHolder@272B5CC] for key [Apache.NMS.ActiveMQ.ConnectionFactory@2428E43] bound to thread [20]
[2008-08-25 15:16:41,910] [20] [DEBUG] [(null)] [(null)] [NmsTemplate] Executing callback on NMS ISession [Apache.NMS.ActiveMQ.Session]

[keenan]

I have seen the enemy, and he is me.

I recently added an ExceptionListener to our message listeners:


#region IExceptionListener Members

public void OnException(Exception exception)
{
NmsTemplate.ConvertAndSend(ErrorQueueName, exception.StackTrace);
}

#endregion


Obviously, if the queueing system is down, then this exception handler will itself generate an exception and infinitely recurse.

Sorry for the false alarm...

[Mark Pollack]

Hi,
No prob. Exceptions thrown in NmsTemplate will not be caught by the template class itself...
Cheers,
Mark