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 Mon, 27 Apr 2009 10:35:30 GMT


Sergey Beryozkin commented on CXF-2002:

Hi Freeman

What is the value of maxSuspendedContinuations that you set for the test ? 
Suppose a loss of messages starts with


I believe that practically  it should be

maxSuspendedContinuations=900, knowing that 1000 is that 'dangerous' limit where the loss
might start occurring... If the test client keeps pumping the input messages then by the time
the server DMLC will get updated with the bogus selector the loss may have already occurred...

> The fix absolutely make things better since I rarely reproduce the message lost problem
now, but the message lost still can happen

I'm nearly sure that if you experiment a bit with maxSuspendedContinuations value then we
can confirm that no loss occurs anymore. Can you please give it another try, by gradually
reducing  maxSuspendedContinuations to that magical value ?

We can then do a recommendation along these lines : if you see the loss of messages with maxSuspendedContinuations=1000
then try decrease the value by 10%.

thanks, 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
> 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