cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Gavlin (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CXF-2002) Server async jms transport needs dynamic mechanism to throttle message consumption
Date Sun, 25 Jan 2009 12:32:01 GMT

    [ 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 internal 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 same technique could be applied to throttle 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.


Mime
View raw message