[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701834#action_12701834
]
Ron Gavlin commented on CXF-2002:
---------------------------------
Below, I have posted some additional implementation-related background
discussion on this feature. To summarize, I suspect stopping/starting the
Spring JMS DMLC is preferred over setting the bogus message selector since
message selectors incur significant overhead on some brokers. Furthermore, we
should probably be careful to set the AcceptMessagesWhileStopping property to
true to ensure we don't lose messages while stopping. Thoughts?
/Ron
<rg> i am looking at techniques for throttling the smx-jms consumer
using some form of pause/resume mechanism. Do you think invoking stop()/start()
on the Spring JMS DMLC is reasonable for such a task?
<gnodet> it could be
<rg> in this case, i presume we would want to set
AcceptMessagesWhileStopping to true, right?
<gnodet> can't we dynamically change the number of consumers
instead ?
<gnodet> not sure if it support that
<gnodet> and not sure if you could set it to 0
<rg> The Spring DMLC requires that concurrentConsumers be >= 1
<rg> CXF-2002 is pausing message ingest by setting a bogus message
selector...
<rg> however, message selectors are very inefficient for some
brokers, especially when there are lots of messages in the queue
<gnodet> we may want to still accept done / errors messages on
the jms side, right ?
<gnodet> in such case, completely pausing the DMLC might be bad
<rg> i am strictly talking about the consumer here
<rg> for the in-only scenario
<rg> for in-out meps, yes, we want to stop the "in" but still leave
the "out" started...do that make sense?
<gnodet> yes
<rg> for the in-out case, we have two distinct DMLCs, correct?
<rg> so to me, start/stop the DMLC is preferred over the bogus
message selector approach...at a high level, would you agree?
<gnodet> i don't have any problems with that
<rg> i think the reason concurrentConsumers must be >= 1 is that if
you want to set to zero the expectation is that you would simply stop the
container...does that make sense?
<gnodet> maybe, but stopping / starting the container might be
more expensive
<gnodet> so we need to take care about not doing that for every
message when at the threshold point
<rg> are you proposing we have a configurable window around the
"maxPendingExchanges" value to avoid overhead issues incurred at the threshold
point?
<gnodet> yeah, that might be a good idea
<gnodet> so that we don't stop/restat the DMLC each time a message has
been handled
> 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
>
> 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.
