[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699425#action_12699425
]
Ron Gavlin commented on CXF-2002:
---------------------------------
Hi Christian,
Let's look at a modified version of the cxf-wsdl-first example in ServiceMix as
an example. This example includes a smx-cxf-bc binding component HTTP consumer
and a smx-cxf-se PersonImpl CXF Pojo implementation. Modify the example by
making the smx-cxf-bc consumer use the JMS transport and set synchronous=false
to cause it send messages to the SMX NMR asynchronously. Also, modify the
called method in the PersonImpl class to sleep for an extended period of time
to represent a longer running task.
Here, I would like to use the maxSuspendedContinuations feature mentioned above
to control the number of message exchanges queued by the NMR for the smx-cxf-se
PersonImpl service. Let's say I want at most 500 suspended continuations. I
would much rather have 500 message exchanges in a queue than have 500 threads
allocated to processing these requests. Using asynchronous JMS "Continuations"
supports this use case and seems like a useful feature, especially in a true
ESB environment.
Does that make sense?
/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: 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.
