GS.Chandra N wrote:
Hi,
I found that if i kept the qpid-tool open long enough all my clients and
publishers would throw exceptions and come out.
qpid-tool keeps a record in-memory of all management objects, including
deleted objects, that it's seen while running. If the broker is
creating and deleting queues, bindings, exchanges, etc. rapidly, the
memory used by qpid-tool will grow.
However, I see no reason why qpid-tool would affect other clients. It
simply creates its own subscription on the broker and binds private
queues to the qpid.management and amq.direct exchanges.
Earlier when i was performing my tests i had 3 putty windows opened to all
the 3 servers and it seems as if, i was keeping qpid-tool opened just long
enough to cause build up but closing it to run top and so on a so forth such
that the memory piled up but did not cause timeouts at the client either.
Observations
1.When there are subscriptions and a qpid-tool around messages seem to pile
up. Why is this so?
qpid-tool should have no effect on the queues owned by other clients.
If a subscription exists (i.e. a binding to an exchange that causes
messages to be enqueued), those message will accumulate unless they are
received and acknowledged by a consumer. If there is no binding that
matches incoming messages, those messages will be discarded immediately
upon reception in the broker.
*
2. When there are no subscribers and no qpid-tool the publishing processes
cause the CPu to go to 90% at the publishing box. But when i started up
subscribers, the publishing box CPU fell to 0% and all the python processes
piled up memory.
Concern : I'm not able to find out here if the publishers are still able to
send out messages at the speed that it should when subscriptions are around.
Or perhaps the broker is not able to pull enough messages - iam not sure
which of this is happeneing. Probably latter? How do i tell?
If i use qpid-tool to connect to the broker at this point, every time i hit
show exchange i get the same stats with the same time stamp. it looks like
the broker is too busy trying to match subscriptions even to refresh the
stats.
3.Concern : Once the subscriptions are made, the CPU at the broker box* *(high
end dual core XEON with ht) goes to 90%. Even at this level, i'm not sure
the broker is able to match and discard all the messages fast enough (due to
2nd observation). Or how do i tell?
If there are subscriptions (bindings with keys that match incoming
messages), the broker does not "match and discard". It will match and
enqueue.
Thanks
gs
ps : Is there a sure shot way to find out the message rates ? (I currently
use qpid-tool show exchange command to find the no of msgRecieves and divide
by time-dfference from 2 times the command is run)
There's a cli utility called "qpid-queue-stats" that does this for you.
It watches queue stats and displays the enqueue and dequeue messages rates.
On Thu, Mar 12, 2009 at 3:11 PM, GS.Chandra N <[email protected]>wrote:
I'm able to reproduce the issue, when i keep qpid-tool open all the time
with the mgmt switches.
However i'm not able to do so if qpid-tool is not open (did not try with
qpid-tool and no mgmt switches).
Thanks
gs
On Thu, Mar 12, 2009 at 1:31 AM, Gordon Sim <[email protected]> wrote:
GS.Chandra N wrote:
ps : Please find attached the scripts that create the issue
I'm afraid I wasn't able to recreate the issue with your tests. Memory
stayed reasonable and constant as the test was running (5 servers, 5
clients).
I'm baffled at this point as to what it is you are seeing.
broker - runs on a dedicated box
qpidd -d --port=5672 --mgmt-enable=yes --mgmt-pub-interval=1 --auth=no
--log-source=yes --log-to-file=/tmp/somename
Do you have qpid-tool or anything else running during the test? Does
turning management off have any impact on the issue?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
