On 07/09/2007, Mohamed Abdelaziz <Mohamed.Abdelaziz_at_sun.com> wrote:
> If there are JMS folks on this list, I would like to hear their
> perspective on managing resource.
I am involved with the AMQP protocol and the Apache Qpid
implementation of that protocol.
I am not sure I fully understand your question so forgive me if I have
missed the point.
With Qpid, we have queues of pending frames on both the client and
server. This means that if a client is publishing rapidly, it does not
need to wait for the broker to have read all the data before the
control is returned to the client application. Obviously certain
operations such as committing a transaction will cause the client
thread to block until the operation has completed.
We have a maximum queue depth so that fast publishers cannot end up
running out of memory (because they just fill up the queue with frames
waiting to be written to the network).
AMQP provides flow control so that a client can regulate how much data
a message broker sends to it. For performance, we allow the broker to
push ("prefetch") data to a client up to a limit. So we also have
delivery queues of messages for each destination that a consumer is
subscribed to.
One thing that is interesting is how much of a message broker is just
reimplementing fundamentally the same thing at different levels. e.g.
TCP is about delivering packets that have an ordering reliably and a
message broker is about delivering (application) messages that have an
ordering reliably.
With all these queues it can be tempting to do everything with
threadpools for each queue. However this means that you do end up
introducing context switching even in cases where nothing should be
building up in the queues. That hurts the case where you have e.g.
fast consumers that can easily keep up with a publisher. So we try to
optimise the cases where things are keeping up and avoid handing off
to other threads. Doing so does get quite tricky since you end up
introducing edge conditions that if not handled correctly can make
preserving the order of messages difficult.
Are there any JMS implementations build on top of Grizzly? I would be
very interested in comparing their performance against Qpid.
RG