[
https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider reassigned CXF-3230:
----------------------------------------
Assignee: Christian Schneider
> 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
> Assignee: Christian Schneider
> Priority: Blocker
> Attachments: CXFJMSResourceLeaking.tar.gz
>
>
> 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.
