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 10:32:14 GMT


Sergey Beryozkin commented on CXF-2002:

Hi Christian

> To avoid loosing continuations each continuation would be persisted to e.g. a queue or
a database

I'm not actually sure that is the case in the JMS case. My understanding is that when a JMS
request thread, the one which has taken a given message off the queue, is 'suspended', through
Continuation.suspend(), what actually happens is that that request thread returns back to
a queue and picks up yet another new message. The original message is kept in memory really,
by the code which will eventually call continuation.resume(), and it will be the thread which
will resume() that will return into the original application code function again.

So in other words, a continuation represents the original JMS request thread initially, and
when it's resumed the original JMS request thread is not there anymore.

Does it help ? Hope I understand it correctly too :-)

> 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