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. 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. - 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). 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? 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
