[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667078#action_12667078
]
rgavlin edited comment on CXF-2002 at 1/25/09 4:31 AM:
----------------------------------------------------------
Hi Christian,
Thanks for looking into this for me.
I am not sure how the Spring SimpleAsyncTaskExecutor relates to the new ASYNC
JMS support implemented in https://issues.apache.org/jira/browse/CXF-1912 using
the new CXF Continuation mechanism
(http://sberyozkin.blogspot.com/2008/12/continuations-in-cxf.html)? Am I
correct that the SimpleAsyncTaskExecutor would only be directly helpful in the
sync JMS case?
In order to apply throttling for the new async CXFContinuation infrastructure,
I was thinking that a property, like "maxSuspendedContinuations" would be
required on the endpoint. In the async, in-out JMS transport case, each
consumed message creates a "suspended" CXF Continuation. The CXF runtime would
be expected to monitor the total number of suspended continuations for this
endpoint. When the value reaches "maxSuspendedContinuations", then CXF would
set the Spring JMS "concurrentConsumers" value to 0. Once the number of
"suspended" CXF continuations drops below the "maxSuspendedContinuations"
threshold, the "concurrentConsumers" value would be increased to a value
greater than 0.
This is the type of dynamic throttling I was envisioning. Does that make sense?
I am not sure if the same technique could be applied to throttle the
continuations mechanism used by the jetty-based http transport.
/Ron
was (Author: rgavlin):
Hi Christian,
Thanks for looking into this for me.
I am not sure how the Spring SimpleAsyncTaskExecutor relates to the new ASYNC
JMS support implemented in https://issues.apache.org/jira/browse/CXF-1912 using
the new CXF Continuation mechanism
(http://sberyozkin.blogspot.com/2008/12/continuations-in-cxf.html)? Am I
correct that the SimpleAsyncTaskExecutor would only be directly helpful in the
sync JMS case?
In order to apply throttling for the new async CXFContinuation infrastructure,
I was thinking that a property, like "maxSuspendedContinuations" would be
required on the endpoint. In the async, in-out JMS transport case, each
consumed message creates a "suspended" CXF Continuation. The CXF runtime would
be expected to monitor the total number of suspended continuations for this
endpoint. When the value reaches "maxSuspendedContinuations", then CXF would
set the Spring JMS "concurrentConsumers" value to 0. Once the number of
"suspended" CXF continuations drops below the "maxSuspendedContinuations"
threshold, the "concurrentConsumers" value would be increased to a value
greater than 0.
This is the type of dynamic throttling I was envisioning. Does that make sense?
I am not sure if the technique could be applied to control the continuations
mechanism used by the jetty-based http transport.
/Ron
> 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: Christian Schneider
> Fix For: 2.2
>
>
> 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.
