HornetQ is just following the STOMP 1.0 spec http://stomp.codehaus.org/Protocol :
"When a client has issued a SUBSCRIBE frame with the ack header set to client any messages received from that destination will not be considered to have been consumed (by the server) until the message has been acknowledged via an ACK."
BTW StompConnect won't do anything different since it just uses the JMS API, and there is no way using JMS to acknowledge an individual message out of order.
Thanks for your reply.
You are right that HornetQ is under no obligation to support out-of-order acknowledgements, I was mistaken. I missed the bit where vanilla JMS doesn't support out-of-order acks. I'm not sure I agree that the STOMP spec is clear in this regard -- it doesn't clarify what "any messages" are in the context of "the message" -- but you are probably right that the intention was to match JMS behaviour.
That said, if I'm not missing anything HornetQ could easily support out-of-order STOMP acks, and my application -- and probably others -- would benefit from it. Would you consider adding this as a feature that can be enabled in the configuration? I'd be happy to provide a patch to this end.
Even better than a configuration option might be to introduce a third ack mode, something pseudo-namespaced like "hornetq:individual" maybe? The STOMP spec does mention ack modes beyond "auto" and "client" in passing... ( http://stomp.codehaus.org/Ack+Modes )
Even betterer: STOMP 1.1 provides a new ack type, client-individual!
It would be fantastic to add support for this prior to adding full STOMP 1.1 support as per HORNET-553. I'll send over a patch shortly.
I took the liberty of creating issue HORNETQ-713 with a patch for this.