cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Gavlin (JIRA)" <>
Subject [jira] Commented: (CXF-2002) Server async jms transport needs dynamic mechanism to throttle message consumption
Date Tue, 12 May 2009 12:35:45 GMT


Ron Gavlin commented on CXF-2002:

Well done, guys! I should have some feedback later today or tomorrow.

I am still concerned about the JMS Broker overhead that will be caused by setting/unsetting
the BOGUS_MESSAGE_SELECTOR. Apparently, when the selector is updated on the consumer, the
broker is forced to re-scan all the messages on the queue in order to "select" which messages
should be targetted for that consumer. If there are thousands of messages on the queue, this
will be an expensive, high-overhead operation for the broker. We are planning to do some performance
testing to verify that this is the case.

OTOH, stopping and starting the connection (via stopping/starting the DMLC) on the client
w/no message selectors is a low-overhead operation from the broker's perspective. It may however
be a higher-overhead operation on the client. 

Again, I'll hopefully provide some more detailed feedback shortly.



> Server async jms transport needs dynamic mechanism to throttle message consumption
> ----------------------------------------------------------------------------------
>                 Key: CXF-2002
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0.9, 2.1.3, 2.0.10
>            Reporter: Ron Gavlin
>            Assignee: Sergey Beryozkin
>         Attachments: CXF-2002.patch
> 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.

View raw message