NMS memory leaks

[starling]

I write simple nms listener with failover. Then I start my app without AciteMQ started, my app start to create failover threads. And do it until I start ActiveMQ.
My Spring config:

  <object id="connectionFactory" type="Spring.Messaging.Nms.Connections.CachingConnectionFactory, Spring.Messaging.Nms">
    <property name="SessionCacheSize" value="10" />
    <property name="TargetConnectionFactory">
      <object type="Apache.NMS.ActiveMQ.ConnectionFactory, Apache.NMS.ActiveMQ">
        <constructor-arg index="0" value="activemq:failover:(tcp://localhost:61616)?transport.timeout=1000&amp;transport.startupMaxReconnectAttempts=1"/>
      </object>
    </property>
  </object>

  <object name="nmsTemplate" type="Spring.Messaging.Nms.Core.NmsTemplate, Spring.Messaging.Nms">
    <property name="ConnectionFactory" ref="connectionFactory"/>
    <property name="DefaultDestinationName" value="foo.bar"/>
  </object>

  <object id="controller" type="Consumer.Controller, Consumer" init-method="Init">
    <constructor-arg ref="nmsTemplate" />
  </object>

Listener creation:

        public void Init()
        {
            SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();
            container.ConcurrentConsumers = 10;
            container.ConnectionFactory = NmsOperations.ConnectionFactory;
            container.DestinationName = "foo.bar";
            container.MessageListener = new MessageListener(this, NmsOperations);
            try
            {
                container.AfterPropertiesSet();
            }
            catch (Exception e)
            {
                Console.WriteLine(e.Message);
            }
        }

[Steve Bohlen]

Issue logged as https://jira.springsource.org/browse/SPRNET-1500.

Thanks for the report,
-Steve B.

[Steve Bohlen]

This is effectively "works as designed"; the container assumes that the messaging middle-ware is functional and attempts to reconnect to it until its healthy again. The only way to really prevent the long-term memory leak here would be to (perhaps) introduce some sort of "MaxMessagingMiddlewareConnectAttempts" setting which would signal the container to enter a "final failure state" once this threshold was reached.

As it is today, this feature isn't really part of the semantic intended behavior of the MessageListenerContainer so I've closed https://jira.spring.io/browse/SPRNET-1500 as "works-as-designed" for at least the time being.