Glad to hear its fixed!
On 2/8/12 10:08 PM, Kai Hackemesser wrote:
[SOLVED]
Hi,
I could fix this issue by setting the CacheConsumers property to false.
Everything clean now.
I would say too that the JMS template need some more maintenance. There is
no method to do a synchronous call. Maybe they have some JMS gateway in
spring integration that I could use. But this time our code is almost
frozen, so maybe next release.
Cheers,
Kai
2012/2/8 Matt Pavlovich<mattr...@gmail.com>
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<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
