Is there any particular reason why exception and session halt were chosen as
the response to full buffer in QPID? We've used ActiveMQ before, and it has
a host of correctness issues and lower performance, but they did seem to
work out the publisher flow control pretty well for topics. I may be
mistaken, but I think if the buffer is full in the broker they just rely on
the TCP protocol itself in the OS to produce the backpressure and flow
control in the publisher.
Such a scheme means that you need a large thread pool or the broker will
starve on CPU. Qpid has been
implemented to be async and process (not-block) and when it can't do so
return the thread. Thus there is
no thread to have back pressure on. this gives higher scalability,
better latency and CPU utilization. In some
of our test with the current trunk it can do about ~ 1.2 Million
msg/second on 4 modern cores, and client
to client latency of ~35us.
One thing to watch with your scheme is that session reject has a
sequence wrap around issue on 0.5, which is
fixed on trunk.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
