You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Hariharan (Updated) (JIRA)" <ji...@apache.org> on 2011/10/15 11:48:11 UTC
[jira] [Updated] (AMQ-3545) JmstTemplate does not close connections
even with PooledConnectionFactory
[ https://issues.apache.org/jira/browse/AMQ-3545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hariharan updated AMQ-3545:
---------------------------
Description:
Hi,
We use AMQ broker 5.5 and Spring 3.0 for configuring connection factory and other stuffs.
The connection factory we are using is PooledConnectionFactory and a part of my config looks like this:
{code:xml}
<bean id="jmsFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="some_url"/>
</bean>
</property>
</bean>
<!-- Spring JMS Template -->
<bean id="jmsTemplate"
class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory">
<ref local="jmsFactory" />
</property>
<property name="explicitQosEnabled" value="true"/>
<property name="timeToLive" value="86400000"/>
</bean>
{code}
A few days back our broker crashed and kept restarting with this error:
# java.lang.OutOfMemoryError: requested
369384 bytes for Chunk::new. Out of swap space?
At that point of time, from jconsole, I could not find anything unusual with the broker, except that one of our client application
which talks with the server (via broker) by sending and listening to messages every *minute* had created ~3000 connections (saw it on jconsole).
Once we had shut it down, everything was back to normal.
So, to avoid this I tried closing the connection in finally block doing something like this.
{code:xml}
try {
connection = myJmsTemplate.getConnectionFactory().createConnection();
session = connection.createSession(false, 1);
String messageSelector = "JMSCorrelationID='" + correlationId + "'";
responseConsumer = session.createConsumer(receiveDestination, messageSelector);
LOG.info("Starting connection");
connection.start();
myJmsTemplate.send(sendDestination, new SimpleTextMessageCreator(
message, receiveDestination, correlationId));
LOG.info("Waiting for message with " + messageSelector + " for " + DEFAULT_TIMEOUT + " ms");
TextMessage responseMessage = (TextMessage) responseConsumer.receive(DEFAULT_TIMEOUT);
}
catch (Someexception e) {do something}
finally {
responseConsumer.close();
session.close();
connection.close();
}
{code}
But even then I can see the connections floating around in jconsole and are only lost if the client app which publishes the messages is brought down.
Can someone please help me understand what's happening here and how I can close the connections after each pub sub cycle.
Thank you in advance,
Hari
was:
Hi,
We use AMQ broker 5.5 and Spring 3.0 for configuring connection factory and other stuffs.
The connection factory we are using is PooledConnectionFactory and a part of my config looks like this:
<bean id="jmsFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy-method="stop">
<property name="connectionFactory">
<bean class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="some_url"/>
</bean>
</property>
</bean>
<!-- Spring JMS Template -->
<bean id="jmsTemplate"
class="org.springframework.jms.core.JmsTemplate">
<property name="connectionFactory">
<ref local="jmsFactory" />
</property>
<property name="explicitQosEnabled" value="true"/>
<property name="timeToLive" value="86400000"/>
</bean>
A few days back our broker crashed and kept restarting with this error:
# java.lang.OutOfMemoryError: requested
369384 bytes for Chunk::new. Out of swap space?
At that point of time, from jconsole, I could not find anything unusual with the broker, except that one of our client application
which talks with the server (via broker) by sending and listening to messages every *minute* had created ~3000 connections (saw it on jconsole).
Once we had shut it down, everything was back to normal.
So, to avoid this I tried closing the connection in finally block doing something like this.
try {
connection = myJmsTemplate.getConnectionFactory().createConnection();
session = connection.createSession(false, 1);
String messageSelector = "JMSCorrelationID='" + correlationId + "'";
responseConsumer = session.createConsumer(receiveDestination, messageSelector);
LOG.info("Starting connection");
connection.start();
myJmsTemplate.send(sendDestination, new SimpleTextMessageCreator(
message, receiveDestination, correlationId));
LOG.info("Waiting for message with " + messageSelector + " for " + DEFAULT_TIMEOUT + " ms");
TextMessage responseMessage = (TextMessage) responseConsumer.receive(DEFAULT_TIMEOUT);
}
catch (Someexception e) {do something}
finally {
responseConsumer.close();
session.close();
connection.close();
}
But even then I can see the connections floating around in jconsole and are only lost if the client app which publishes the messages is brought down.
Can someone please help me understand what's happening here and how I can close the connections after each pub sub cycle.
Thank you in advance,
Hari
> JmstTemplate does not close connections even with PooledConnectionFactory
> -------------------------------------------------------------------------
>
> Key: AMQ-3545
> URL: https://issues.apache.org/jira/browse/AMQ-3545
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Reporter: Hariharan
> Labels: activemq
>
> Hi,
> We use AMQ broker 5.5 and Spring 3.0 for configuring connection factory and other stuffs.
> The connection factory we are using is PooledConnectionFactory and a part of my config looks like this:
> {code:xml}
> <bean id="jmsFactory" class="org.apache.activemq.pool.PooledConnectionFactory" destroy-method="stop">
> <property name="connectionFactory">
> <bean class="org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL" value="some_url"/>
> </bean>
> </property>
> </bean>
> <!-- Spring JMS Template -->
> <bean id="jmsTemplate"
> class="org.springframework.jms.core.JmsTemplate">
> <property name="connectionFactory">
> <ref local="jmsFactory" />
> </property>
> <property name="explicitQosEnabled" value="true"/>
> <property name="timeToLive" value="86400000"/>
> </bean>
> {code}
> A few days back our broker crashed and kept restarting with this error:
> # java.lang.OutOfMemoryError: requested
> 369384 bytes for Chunk::new. Out of swap space?
> At that point of time, from jconsole, I could not find anything unusual with the broker, except that one of our client application
> which talks with the server (via broker) by sending and listening to messages every *minute* had created ~3000 connections (saw it on jconsole).
> Once we had shut it down, everything was back to normal.
> So, to avoid this I tried closing the connection in finally block doing something like this.
> {code:xml}
> try {
> connection = myJmsTemplate.getConnectionFactory().createConnection();
> session = connection.createSession(false, 1);
> String messageSelector = "JMSCorrelationID='" + correlationId + "'";
> responseConsumer = session.createConsumer(receiveDestination, messageSelector);
> LOG.info("Starting connection");
> connection.start();
> myJmsTemplate.send(sendDestination, new SimpleTextMessageCreator(
> message, receiveDestination, correlationId));
> LOG.info("Waiting for message with " + messageSelector + " for " + DEFAULT_TIMEOUT + " ms");
> TextMessage responseMessage = (TextMessage) responseConsumer.receive(DEFAULT_TIMEOUT);
> }
> catch (Someexception e) {do something}
> finally {
> responseConsumer.close();
> session.close();
> connection.close();
> }
> {code}
> But even then I can see the connections floating around in jconsole and are only lost if the client app which publishes the messages is brought down.
> Can someone please help me understand what's happening here and how I can close the connections after each pub sub cycle.
> Thank you in advance,
> Hari
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira