[
https://issues.apache.org/jira/browse/CXF-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699537#action_12699537
]
Christian Schneider commented on CXF-2002:
------------------------------------------
Hi Ron,
would this mean that you first read 500 messages from the queue and create a
suspended continuation for each. Then the servicemix nmr would read one
continuation after the other and let the pojo work on them. To avoid loosing
continuations each continuation would be persisted to e.g. a queue or a
database. Did I get how it works?
What bothers me is that this model has to be included in each transport.
Shouldn´t continuations better be separated from the transports in some sort of
handler between transport and higher levels? What I would ideally want to see
on the receiving side of a transport is that it takes the messages from a
listener and forwards them to a pipeline. Of course there should be some kind
of throttling where the pipeline may say "I currently can not take any more
messages". But how this throttling is done I would rather see completely
outside the transport.
If my asumptions at the start are correct about how continuations work then
what bothers me is that all the 500 suspended continuations would first be
taken from the queue only to put them on another persistent media. Wouldn´t it
be better to only read from the queue if there are free "workers" that can
handle the message? In the sync case you could use a ThreadPoolTaskexecutor to
allow a certain number of workers in parallel. For an async case it could work
to implement a TaskExceutor that uses continuations.
See
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/core/task/TaskExecutor.html
Would this solve the problem?
The nice thing here would be that the scheduling is separated from the JMS
Transport and could perhaps even be reused for different transports. On the
other hand perhaps continuations offer the same thing. In any case I would like
to have only one way in the JMS transport so it does not have to care about how
the further processing works. Of course it may be a good idea to
havecontinuations now in the transport if they are needed. But in the long run
we should avoid building too much into each transport.
Greetings
Christian
> 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
> 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.
