Return-Path: 
 <issues-return-15883-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: (qmail 77857 invoked from network); 3 Feb 2011 06:48:54 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 3 Feb 2011 06:48:54 -0000
Received: (qmail 15530 invoked by uid 500); 3 Feb 2011 06:48:54 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 15421 invoked by uid 500); 3 Feb 2011 06:48:52 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 15413 invoked by uid 99); 3 Feb 2011 06:48:52 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 06:48:52 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Feb 2011 06:48:50 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id E7C0D18A2F6
	for <issues@cxf.apache.org>; Thu,  3 Feb 2011 06:48:29 +0000 (UTC)
Date: Thu, 3 Feb 2011 06:48:29 +0000 (UTC)
From: "Christian Schneider (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1735300506.6826.1296715709945.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <8089556.138431294164527023.JavaMail.jira@thor>
Subject: [jira] Resolved: (CXF-3230) CXF over JMS leaks JMS resources  when
 no replay queue is specified
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


     [ https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider resolved CXF-3230.
--------------------------------------

    Resolution: Fixed

The problem with deleting the temp queue in HornetQ can probably be fixed by the HornetQ team. The workaround for CXF 2.3.3 will allow users to have their calls working even if the temp queue is not deleted. Will reopen the issue if the HornetQ team can not fix the problem.

> 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
>             Fix For: 2.3.3
>
>         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="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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira