qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Qpidmessaging client sends too many flows to ActiveMQ broker (vs qpidd broker)
Date Wed, 15 Oct 2014 20:09:39 GMT
I'm working on comparing AMQP 1.0 clients with different brokers. In this case
I have ActiveMQ 5.10 and Qpidd brokers on a Fedora 19 localhost. For the client I
have a qpidmessaging client test that moves unreliable messages.

The test client program:
    For the full source please see 

 0. Uses 400 total messages with a 'batch' size of 50.

 1. Creates a connection to:
    "chuck; {create:always, link: {reliability:unreliable}}"

 2. Creates a sender and receiver each with capacity of 100.

 3. Sends a batch to the broker

 4. Loops sending and receiving batches of messages

 5. Receives the final batch.

 The idea is to prime the broker with a batch of messages. Then send and
 receive batches so that the receiver might never have to wait doing a
 fetch because the receiver's capacity will prefetch the messages.

The results:
 Each broker ran from a fresh boot. Only one broker ran at a time.

 With Qpidd the client gets through the 400 messages in 8 +/- 3 mS. The AMQP
 transfer-to-flow ratio is very high and efficient.

 With ActiveMQ 5.10 the clients takes 260 +/- 60 mS. The AMQP transfer-to-flow
 ratio is much lower. Additionally, the client sends frames to the host where 
 the payload is nothing but a dozen flow performatives (see frame 138 below).
 This is the exact same client that worked so well with Qpidd.

 To visualize the traffic please see:


1) Is this a real issue, and if so with which module?

It looks like the qpidmessaging client spits out a flow for each message it receives 
from the broker and then some. That makes sense until the back-to-back flow frames
start piling up. In one trace with 2000 messages I saw 700 consecutive flow frames from the
client to
the broker but this is not repeatable.

Both brokers wind up transferring the same payload in the end. But maybe if the
client did things a little differently the ActiveMQ broker could do it more quickly.

2) Another late observation in the ActiveMQ broker trace is:

 ◊  ◊◊  Frame 67  [::1]:47813  -> [::1]:5672  8.478287 [transfer [0,1] (47) .. transfer
[0,1] (99)]
 ◊  ◊◊  Frame 68  [::1]:47813  -> [::1]:5672  8.487341 [transfer [0,1] (47) .. transfer
[0,1] (99)]

 Here the client is sending the same batch of messages (47..99) twice with the second being
 TCP Retransmission and a lost 10mS between the two. This same retransmission is in the
 two traces from different runs that I've saved so it is somewhat repeatable.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message