cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] Commented: (CXF-2002) Server async jms transport needs dynamic mechanism to throttle message consumption
Date Thu, 16 Apr 2009 11:05:14 GMT


Sergey Beryozkin commented on CXF-2002:

Hi Ron

> What would you think about setting a bogus selector on the DefaultMessageListenerContainer
to suspend message consumption?  That appears to be the technique used to implement JMS-based
throttling in the new SMX4 Cluster Endpoint

Sounds like a neat idea. Suppose we just set some bogus selector like "org.apache.cxf.jms.continuations.too-many"
so it will keep the incoming messages in the queue till the original selector is restored.

I was also thinking about simply blocking the request threads for the time specified in suspend()
- it would keep the JMS thread blocked and thus all the existing JMS request threads will
eventually be locked till a number of continuations decreases - but I'm not 100% sure it would
actually prevent the JMS runtime from creating new JMS threads which would continue pump new
messages into the memory.

What do you think about this second idea ?
cheers, Sergey

> 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
>             Fix For: 2.2.1
> 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