activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Stomp, acking and prefetchSize
Date Mon, 07 Apr 2008 15:34:48 GMT
On Tue, Mar 18, 2008 at 7:41 AM, Dejan Bosanac <dejan@nighttale.net> wrote:
> Hi,
>
>  there're some interesting issues with Stomp protocol and acking messages ...
>
>  If you write a simple consumer that subscribes to the queue, reads one
>  message, acks it and disconnects, you can easily end up with your
>  message not being acked (if you are using default settings) in case
>  your queue has a fair number of messages (>10).
>
>  This happens because default prefetchSize is set to 1000 and the
>  broker tries to send as much messages as it can, so if an ack command
>  is sent over the network it simply sometimes does not arrive before
>  consumer disconnects.

The client should send the DISCONNECT command to the broker and wait
for the socket to get
closed by the peer if we wants to ensure that all the previously
transmitted commands are processed by the broker.

>
>  This is solved by setting prefetchSize to 1, but I'm wondering is
>  there any clever way we can deal with it?
>
>  There are other issues with this large prefetchSize as well:
>
>  - in autoack mode, even if you really consume one message, 10 or so
>  messages are being acked as Stomp subscriber acks every message as it
>  sends it.
>

Yeah this is an known issue.  This might be the best reason to set the
prefetch size down to 1.  Or just set it to 1 by default when using
auto ack.  Even then it's going to auto ack as many messages as it can
fit in the network buffers.  Robust STOMP clients are going to have to
client ACK.

>  - it's harder to make the client work in sync mode, since it has to
>  discard (or buffer) a large number of messages before it find its
>  receipt (which complicate presumably a simple library).

sync mode?

>
>  Since the purpose of Stomp clients is to be simple (hence a simple
>  protocol) and not lightning fast, maybe we should go with
>  prefetchSize=1 by default on amq side? This will allow correct default
>  behavior with good enough performance for most of the use cases. And
>  people with more performance requirements can always fall back to
>  incresing prefetchSize and async operations. Or is it better to
>  control this on client side?
>

So far I think prefetchSize=1 would a good default when using auto
ack.. I still don't see why a big prefetch would be a problem with
client ack.

Regards,
Hiram

>  Some other options are:
>
>  - to solve lost acks, we can (I think) refuse to disconnect (on the
>  client) unitl we have any data left to be read on the socket.
>  - document the importance of prefetchSize to users so that they don't
>  fall to autoack trap
>  - reimplement the "wait for receipt" logic
>
>  but it seems to me that defaulting prefetchSize to 1 would be by far
>  the best solution.
>
>  Any thoughts on this are more then welcomed ....
>
>  Thanks
>  --
>  Dejan Bosanac
>  www.scriptinginjava.net
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Mime
View raw message