Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain nabble.com designates
 72.21.53.35 as permitted sender)
Message-ID: <6491196.post@talk.nabble.com>
Date: Mon, 25 Sep 2006 10:26:00 -0700 (PDT)
From: Rob Lugt <robert.lugt@cheynecapital.com>
To: activemq-users@geronimo.apache.org
Subject: Re: Topic consumer appears throttled
In-Reply-To: <ec6e67fd0609221009s4268588ai777046feab449ad@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2092_13226359.1159205160506"
References: <6451007.post@talk.nabble.com>
 <ec6e67fd0609221009s4268588ai777046feab449ad@mail.gmail.com>

------=_Part_2092_13226359.1159205160506
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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.

------=_Part_2092_13226359.1159205160506--