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.hackemes...@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
