cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <>
Subject [jira] Updated: (CXF-3230) CXF over JMS leaks JMS resources when no replay queue is specified
Date Thu, 06 Jan 2011 11:46:50 GMT


Christian Schneider updated CXF-3230:

    Attachment: CXF-3230.patch

Added a patch to delete the temp queue after the request is finished. On my system this fixes
the problem.

I have also committed this to the trunk so you can test this by applying the patch yourself
or you can wait till the snapshot release is deployed (tomorrow I guess) and use this. 

> CXF over JMS leaks JMS resources  when no replay queue is specified
> -------------------------------------------------------------------
>                 Key: CXF-3230
>                 URL:
>             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
>             Fix For: 2.3.2
>         Attachments: CXF-3230.patch, 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="">
> 				<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.

View raw message