activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kai Hackemesser <kai.hackemes...@gmail.com>
Subject Re: strange topic subscriptions not disappearing [V5.5.1]
Date Thu, 09 Feb 2012 04:08:00 GMT
[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 <mattrpav@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.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
>>>
>>>
>>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message