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.
I think that's how it was tested (by I'm not sure at the moment). I'll give it a bit more testing to see if maybe there is a bug on the client side. > 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. Cool. I'll document it for future reference. > - 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? When you are waiting for receipts... For example, you subscribe to the queue that has 100 messages, read the first message, send ack and try to get a receipt for it, but there is a lot of messages to be read before your receipt gets its turn. 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. I've implemented easy way to set defaultPrefetch size in PHP client, so I guess all we need is a piece of docs advising users on appropriate values for specific use cases Thanks -- Dejan Bosanac www.scriptinginjava.net
