Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Date: Tue, 7 Jan 2014 15:04:19 -0800 (PST)
From: uromahn <ulrich@ulrichromahn.net>
To: users@activemq.apache.org
Message-ID: <1389135859436-4676090.post@n4.nabble.com>
In-Reply-To: <1388891353027-4676012.post@n4.nabble.com>
References: <1388794098280-4676001.post@n4.nabble.com>
 <1388891353027-4676012.post@n4.nabble.com>
Subject: Re: Interesting Persistent Messaging Performance
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The AMQP client does not use asynchronous communication with the server. This
is embedded in the AMQP protocol, so the client sends the message and the
call to "send(msg)" only returns after the client received an ack
confirmation from the broker via the protocol.

What I don't know, however, is how the AMQP protocol connector within
ActiveMQ works. It could be that the connector confirms the message before
it actually got committed to the persistent store and hence the significant
different performance numbers.
The best way to test this would be to send a large number of messages to the
broker, then kill the broker process and compare the number of sent messages
on the client with the number of messages enqueued on the broker. If there
is a difference (i.e. less messages on the broker), then we lost some
messages and the guarantee is violated. This would then be a clear bug in
the AMQP connector within ActiveMQ.

You may hear from me back on the result of my test.


--
View this message in context: http://activemq.2283324.n4.nabble.com/Interesting-Persistent-Messaging-Performance-tp4676001p4676090.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.