CXF over JMS leaks JMS resources when no replay queue is specified
-------------------------------------------------------------------
Key: CXF-3230
URL: https://issues.apache.org/jira/browse/CXF-3230
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 2.3.1
Environment: Linux, ActiveMQ 5.4.2 and HornetQ 2.1.2
Reporter: Kjell Winblad
Priority: Blocker
This issue was found both when testing with ActiveMQ 5.4.2 and HornetQ 2.1.2 as
JMS provider. The JMS settings is set in the WSDL file:
<service name="TestJMS">
<port binding="tns:TestBinding" name="Test">
<address destinationStyle="queue"
jndiConnectionFactoryName="ConnectionFactory"
jndiDestinationName="dynamicQueues/messageDestination"
xmlns="http://cxf.apache.org/transports/jms";>
<JMSNamingProperty
name="java.naming.provider.url"
value="tcp://localhost:61616?jms.watchTopicAdvisories=false"/>
<JMSNamingProperty
name="java.naming.factory.initial"
value="org.apache.activemq.jndi.ActiveMQInitialContextFactory"/>
</address>
</port>
</service>
The issue was found when performing a test with a server and a client both
created with CXF. The client has an infinite loop that performs a request on
the server and waits for a response before the next iteration is executed.
After a couple of thousands of request response iterations have been performed
the JMS provider starts to get very slow and ActiveMQ gets out of memory if the
test is run long enough. First I thought it was a configuration problem with
the JMS provider or a bug in ActiveMQ, but because the same problem exists both
with HornetQ and several configurations of ActiveMQ it seems like it is a
problem with CXF.
When monitoring ActiveMQ with jconsole it can be seen that when ActiveMQ is set
to not use a thread pool (-Dorg.apache.activemq.UseDedicatedTaskRunner=true),
the number of threads grows while the test is running and no threads seem to be
deallocated. When a thread pool is used the number of threads is quite constant
but the amount of memory on the heap still grows. No leak is observed when a
response queue is specified with jndiReplyDestinationName. So when a temporary
queue should be used to send back the replay it seems like one replay queue is
created for every replay and they never get removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
