You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2009/05/04 10:48:30 UTC
[jira] Commented: (CXF-2002) Server async jms transport needs
dynamic mechanism to throttle message consumption
[ https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705526#action_12705526 ]
Freeman Fang commented on CXF-2002:
-----------------------------------
Hi Sergey,
The good news is until now I can't reproduce the message lost problem.
But another issue I've found is the message leak problem with jms continuation, let's say the server side recieved 1001 message
then I saw the class instance like (get it by "jmap -histo:live" with jdk6)
instance_count size
51: 2002 128128 org.apache.cxf.message.MessageImpl
66: 2004 96192 org.apache.cxf.phase.PhaseInterceptorChain
67: 2002 96096 org.apache.cxf.transport.jms.JMSMessageHeadersType
77: 1001 72072 org.apache.cxf.message.ExchangeImpl
88: 1001 56056 org.apache.cxf.transport.jms.JMSOutputStream
99: 1001 48048 org.apache.cxf.ws.addressing.AddressingPropertiesImpl
100: 1001 48048 org.apache.cxf.transport.jms.continuations.JMSContinuation
101: 2002 48048 org.apache.cxf.phase.PhaseInterceptorChain$PhaseInterceptorIterator
113: 2088 33408 org.apache.cxf.common.util.SortedArraySet
116: 1003 32096 org.apache.cxf.ws.addressing.EndpointReferenceType
120: 1001 32032 org.apache.cxf.transport.jms.continuations.JMSContinuationProvider
121: 2002 32032 org.apache.cxf.binding.soap.SoapMessage
122: 1001 32032 org.apache.cxf.transport.jms.JMSDestination$BackChannelConduit
124: 1001 32032 org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor
161: 1003 16048 org.apache.cxf.ws.addressing.AttributedURIType
162: 1001 16016 org.apache.cxf.staxutils.DepthXMLStreamReader
163: 1001 16016 org.apache.cxf.helpers.LoadingByteArrayOutputStream
164: 1001 16016 org.apache.cxf.endpoint.PreexistingConduitSelector
never get released, so if sever run after long term, we will encouter the OOM exception.
I guess this might be another issue, so please create a new ticket if you feel it's necessary.
Btw, I also see same memory leak problem with cxf http continuation.
Thanks
Freeman
> Server async jms transport needs dynamic mechanism to throttle message consumption
> ----------------------------------------------------------------------------------
>
> Key: CXF-2002
> URL: https://issues.apache.org/jira/browse/CXF-2002
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.0.9, 2.1.3, 2.0.10
> Reporter: Ron Gavlin
> Assignee: Sergey Beryozkin
>
> Currently, the server-side async jms transport has no mechanism to throttle consumption of incoming messages. This becomes problematic in scenarios where a large backlog of messages exists on the input queue. In this case, it is likely that the cxf server will overload its internal work item queues resulting in problems. A dynamic throttling mechanism on the async jms server is required to avoid this problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.