cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2002) Server async jms transport needs dynamic mechanism to throttle message consumption
Date Thu, 23 Apr 2009 12:33:47 GMT

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


Mime
View raw message