[
https://issues.apache.org/jira/browse/CXF-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981799#action_12981799
]
Kjell Winblad commented on CXF-3230:
------------------------------------
Thanks for the fast fix attempt. Unfortunately it seems like there still is a
problem.
When testing with ActiveMQ it works when adversary messages is switched on. The
ActiveMQ documentation (http://activemq.apache.org/advisory-message.html) says
that adversary messages must be enabled for temporary queues to work.
When doing the same test but with ActiveMQ replaced with HornetQ the client
crashes with the following exception. The same test worked before the patch but
then the mq was leaking resources. It seems like the session for which the temp
queue is created has been closed before the attempt to to delete the queue. Is
that the case or shall this issue be reported to HornetQ?
INFO: Established shared JMS Connection:
org.hornetq.jms.client.HornetQConnection@12381a9c
Jan 14, 2011 10:46:41 AM org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
WARNING: Interceptor for {http://testjms}TestJMS#{http://testjms}testOp has
thrown exception, unwinding now
java.lang.RuntimeException: Unable to remove temporary queue
at
org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:249)
at
org.apache.cxf.transport.jms.JMSOutputStream.doClose(JMSOutputStream.java:56)
at
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:185)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
at $Proxy39.testOp(Unknown Source)
at Client.main(Client.java:28)
Caused by: javax.jms.IllegalStateException: Session is closed
at
org.hornetq.core.client.impl.ClientSessionImpl.checkClosed(ClientSessionImpl.java:1643)
at
org.hornetq.core.client.impl.ClientSessionImpl.queueQuery(ClientSessionImpl.java:346)
at
org.hornetq.core.client.impl.DelegatingSession.queueQuery(DelegatingSession.java:436)
at
org.hornetq.jms.client.HornetQSession.deleteTemporaryQueue(HornetQSession.java:922)
at
org.hornetq.jms.client.HornetQDestination.delete(HornetQDestination.java:266)
at
org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:247)
... 12 more
Caused by: HornetQException[errorCode=102 message=Session is closed]
... 18 more
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Unable to
remove temporary queue
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:146)
at $Proxy39.testOp(Unknown Source)
at Client.main(Client.java:28)
Caused by: java.lang.RuntimeException: Unable to remove temporary queue
at
org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:249)
at
org.apache.cxf.transport.jms.JMSOutputStream.doClose(JMSOutputStream.java:56)
at
org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:185)
at
org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:247)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:313)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:265)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
... 2 more
Caused by: javax.jms.IllegalStateException: Session is closed
at
org.hornetq.core.client.impl.ClientSessionImpl.checkClosed(ClientSessionImpl.java:1643)
at
org.hornetq.core.client.impl.ClientSessionImpl.queueQuery(ClientSessionImpl.java:346)
at
org.hornetq.core.client.impl.DelegatingSession.queueQuery(DelegatingSession.java:436)
at
org.hornetq.jms.client.HornetQSession.deleteTemporaryQueue(HornetQSession.java:922)
at
org.hornetq.jms.client.HornetQDestination.delete(HornetQDestination.java:266)
at
org.apache.cxf.transport.jms.JMSConduit.sendExchange(JMSConduit.java:247)
... 12 more
Caused by: HornetQException[errorCode=102 message=Session is closed]
... 18 more
> 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.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="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.
