[ 
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708413#action_12708413
 ] 

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.

Thanks,

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

Reply via email to