On Tue, Mar 18, 2008 at 7:41 AM, Dejan Bosanac <[EMAIL PROTECTED]> 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
