[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701911#action_12701911
]
Sergey Beryozkin commented on CXF-2002:
---------------------------------------
Ron,
First of all I'd like to see maxSuspendedContinuations working using the
current approach (using the bogus selector) so we'll work with Freeman to make
sure it works as expected.
> 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
Just checking : are you talking about the solution at the SMX4 level
(....configurable window around the "maxPendingExchanges"...) ?
I'm a bit pessimistic about starting exploring this new option in CXF at the
moment. Bogus selectors are used by SMX4 JBI cluster implementations and
apparently they do work.
My question is : how effective would the new proposed solution be across
multiple brokers, stopping/restarting the in-DMLC, even with the window around
maxSuspendedContinuations, compared to using the bogus selector, given that
we're talking about arguably a fairly transient case, when a number of
continuations is too high ?
My other concern is that it would be hard to ensure it can be done atomically
and efficiently at the CXF level without introducing some additional
synchronization. For example, at the moment an individual continuation instance
can checks the (concurrent) list storing the active continuations for its
size(), and then set the bogus selector if needed, with the minor race
condition that it this update can happen few times in parallel for ex. Same for
restoring the original value.
But we'd need to synchronize both on the continuations list and on the in-DMLC
instance to make sure we don't call stop when start is being executed, etc -
I'm worried it can get a bit messy and offset the possible savings (?) of the
new proposed approach
cheers, Sergey
> 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.
