You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Kai Hackemesser <ka...@gmail.com> on 2012/02/08 00:40:45 UTC
strange topic subscriptions not disappearing [V5.5.1]
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
Re: strange topic subscriptions not disappearing [V5.5.1]
Posted by Matt Pavlovich <ma...@gmail.com>.
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<ma...@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<ka...@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
>>>>
>>>>
>>>>
Re: strange topic subscriptions not disappearing [V5.5.1]
Posted by Kai Hackemesser <ka...@gmail.com>.
[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 <ma...@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<ka...@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
>>>
>>>
>>>
Re: strange topic subscriptions not disappearing [V5.5.1]
Posted by Matt Pavlovich <ma...@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<ka...@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
>>
>>
Re: strange topic subscriptions not disappearing [V5.5.1]
Posted by Kai Hackemesser <ka...@gmail.com>.
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 <ka...@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
>
>