Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <1825665681.1232886721638.JavaMail.jira@brutus>
Date: Sun, 25 Jan 2009 04:32:01 -0800 (PST)
From: "Ron Gavlin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Issue Comment Edited: (CXF-2002) Server async jms transport
 needs dynamic mechanism to throttle message consumption
In-Reply-To: <1839152316.1232770559952.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.