[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703055#action_12703055
]
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
maxSuspendedContinuations=1000
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: 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.
