Spring Caching connection factory has been reported to have a number of 
issues.  I do not have a specific bug ticket or link, but I hear about 
it quite a bit.  I would suggest trying to just use ActiveMQ's 
connection factory, instead of Spring's and see if that helps.

If that doesn't fix it, be sure that your JmsUtils.close*() methods call 
the "close()" method, and null set the objects in the finally block.

Side note-- I'm not a big fan of Spring's JmsTemplate in general.  
ActiveMQ provides an impl of the JMS API, and I think that provides a 
simple enough abstraction.  It seems to me that adding the Spring layer 
on top just adds a layer of complexity.  My $0.02.

Hope this helps,
Matt Pavlovich

On 2/7/12 6:09 PM, Kai Hackemesser wrote:
> More details to the issue: This is how I configured the JmsTemplate:
>
>      public @Bean
>      JmsTemplate jmsTemplate() {
>          JmsTemplate template = new JmsTemplate();
>          template.setConnectionFactory(cachingConnectionFactory());
>          template.setDeliveryPersistent(false);
>          return template;
>      }
>
>      @Bean
>      public CachingConnectionFactory cachingConnectionFactory() {
>          CachingConnectionFactory factory = new CachingConnectionFactory();
>          factory.setReconnectOnException(true);
>          factory.setTargetConnectionFactory(jmsConnectionFactory());
>          return factory;
>      }
>
>      @Bean
>      public ActiveMQConnectionFactory jmsConnectionFactory() {
>          Assert.notNull(clientProperties().getJmsBrokerConnectionString(),
>              "JMS Broker not set in configuration properties");
>          ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory();
>
> factory.setBrokerURL(clientProperties().getJmsBrokerConnectionString());
>          return factory;
>      }
>
> Using org.apache.activemq.ActiveMQConnectionFactory
> and org.springframework.jms.connection.CachingConnectionFactory from Spring
> 3.1.0
>
> BTW the number has just grown from 37 to 5429 subscriptions.
>
> Cheers,
> Kai
>
>
> 2012/2/8 Kai Hackemesser<kai.hackemesser@gmail.com>
>
>> Hi there,
>>
>> we are still testing AciveMQ in preproduction here. Imagine following
>> situation:
>>
>> we have two topics here that work as a request/response pair. The data
>> producer is permanently(not durable) subscribed to the request topic and
>> puts its payload into the response topic. The client uses a JMS Template
>> with a SessionCallback to sends its data requests to the request topic and
>> awaits responses in the response topic. Here the code that matters:
>>
>>      @Override
>>      public Message doInJms(final Session session) throws JMSException {
>>          MessageConsumer consumer = null;
>>          MessageProducer producer = null;
>>          try {
>>              final String correlationId = UUID.randomUUID().toString();
>>
>>              consumer = session.createConsumer(responseDestination,
>> "JMSCorrelationID = '" + correlationId + "'");
>>
>>              final ObjectMessage message =
>> session.createObjectMessage(payload);
>>              message.setJMSCorrelationID(correlationId);
>>              message.setStringProperty("CLIENT_ID", clientUid);
>>              message.setStringProperty("GSE_ID", gseUid);
>>              producer = session.createProducer(requestDestination);
>>              producer.send(message);
>>
>>              return consumer.receive(TIMEOUT);
>>          } finally {
>>              // Don't forget to close your resources
>>              JmsUtils.closeMessageConsumer(consumer);
>>              JmsUtils.closeMessageProducer(producer);
>>          }
>>      }
>>
>>  From my understanding this creates the consumer, subscribes to the
>> response topic, creates the producer, sends the request, waits for the
>> response or the timeout(5000) and then finally closes producer and consumer
>> on the client side. Nevertheless I found by chance on the JMX console that
>> our running client has created subscriptions to the topic that sit there
>> constantly and aren't closed. Currently there are 37 connections to the
>> response topic, all coming from one connection. How could that happen?
>>
>> cheers,
>> Kai
>>
>>