[ 
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699627#action_12699627
 ] 

Sergey Beryozkin commented on CXF-2002:
---------------------------------------

Hi Christian

> To avoid loosing continuations each continuation would be persisted to e.g. a 
> queue or a database

I'm not actually sure that is the case in the JMS case. My understanding is 
that when a JMS request thread, the one which has taken a given message off the 
queue, is 'suspended', through Continuation.suspend(), what actually happens is 
that that request thread returns back to a queue and picks up yet another new 
message. The original message is kept in memory really, by the code which will 
eventually call continuation.resume(), and it will be the thread which will 
resume() that will return into the original application code function again.

So in other words, a continuation represents the original JMS request thread 
initially, and when it's resumed the original JMS request thread is not there 
anymore.

Does it help ? Hope I understand it correctly too :-)

> 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
>             Fix For: 2.2.1
>
>
> 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.

Reply via email to