Many thanks for the patch Rob, I've applied it.
Incidentally if you can think of a cleaner way of implementing the
threading in .Net we'd welcome patches - to be perfectly honest I'm a
bit of a newbie C# developer so have been guessing a little in the
threading code. (It took a long time to figure out how to do the
equivalent of Java's wait() & notifiy() :)
On 9/25/06, Rob Lugt <[EMAIL PROTECTED]> wrote:
James.Strachan wrote:
>
> This sounds like it could be related to acknowledgements - you're
> using NMS and C# as the client right? What acknowledgement mode are
> you using and are you using the async or sync listener?
>
Hi James, your initial thought's on this were correct - the problem is due
to acknowledgements. After finding that the Java client did not suffer the
same problems, I took the plunge and debugged the C# NMS code.
I've discovered 2 issues:-
Firstly, the prefetch size for all consumers appears to be fixed at 1000 for
.Net clients. The statement
private int prefetchSize = 1000;
in ActiveMQ\Session.cs gives the game away on that one. I tried modifying
this to 2000 on my machine and hey-presto my test case worked. Of course I
only had to increase the publisher to push out 2500 messaghes for the
problem to return, so even though this was encouraging it was not the end of
the story.
Secondly, the real problem appears to be due to resource starvation within
MessageConsumer.DispatchAsyncMessages(). This method will continue
processing input messages as long as there are any messages queued, but the
effect of this is that asynchroous acknowledgements will not be dispatched
until all inbound messages have been processed. Adding a break statement
into the function solves the problem. e.g:
public void DispatchAsyncMessages()
{
while (listener != null)
{
IMessage message = dispatcher.DequeueNoWait();
if (message != null)
{
//here we add the code that if do acknowledge action.
message = AutoAcknowledge(message);
listener(message);
break; // RAL 25/09/2006: Return to allow queued messages to be
processed
}
else
{
break;
}
}
}
So, that appears to solve my little problem, although I am still a little
concerned about the instability this bug managed to cause my environment
earlier today.
Having taken a quick look through the NMS code I can see that I'm going to
have other questions e.g.
Use of ThreadPool - I was expecting all callbacks for a Session to occur on
a single thread
Lack of programability of the .Net classes (prefetch size is an example)
... but I guess the developer forum is a better location for questions of
this sort.
Best regards
Rob Lugt
--
View this message in context:
http://www.nabble.com/Topic-consumer-appears-throttled-tf2318926.html#a6491196
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
James
-------
http://radio.weblogs.com/0112098/
