cxf-issues mailing list archives

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


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



> 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