activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Lugt (JIRA)" <>
Subject [jira] Updated: (AMQ-999) Message dispatcher issues (use dedicated dispatching thread for each session)
Date Tue, 24 Oct 2006 10:51:02 GMT
     [ ]

Rob Lugt updated AMQ-999:

    Attachment: amq999-patch.txt

Patch to use dedicated DispacherThread instead of the application ThreadPool.

In addition to using the dedicated thread, this patch also moves the NMS client closer to
the JMS specification:

Connection.Start() and Connection.Stop() now perform as advertised for asynchronous message
delievery (but they have no affect on synchronous delivery).  The big difference between JMS
and NMS at the moment is that a new session is started by default (whereas a JMS connection
is stopped I believe).  I've done this to ensure backwards compatability with existing .Net
users, but am more than happy for it to be reversed to align with JMS.

Retroactive consumers are catered for by setting the message delivery event at the same tiem
as registering an asynchronous even listener - so that messages already received  will be
delivered immediately.

Where applicable I've also added Close methods to compliment Dispose() and to make both Close
and Dispose behave correctly when called multiple times.

Use of a dedicated dispatching thread improves message throughput in my test client by about

> Message dispatcher issues (use dedicated dispatching thread for each session)
> -----------------------------------------------------------------------------
>                 Key: AMQ-999
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: NMS (C# client)
>    Affects Versions: 4.0.2
>         Environment: Windows
>            Reporter: Rob Lugt
>         Assigned To: Rob Lugt
>         Attachments: amq999-patch.txt, AtomicBoolean.cs, DispatchingThread.cs
> There are a number of issues with the dispatching of inbound messages.
> - A slow consumer will potentially use and block all ThreadPool threads
> - Use of a ThreadPool thread to dispatch a single message is inefficient due to context
> - No mechanism to suspend asynchronous delivery to a session (i.e. Connection.Stop()
is currently a no-op)
> - Retroactive consumer is currently broken because retoractive messages are delivered
before the listener delegate is assigned.
> - [minor] Application cannot predict which thread messages will be dispatched on
> All of these problems can simply be resolved by creating a dedicated dispatcher thread
for a session

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message