2008/5/28 TLFox <[EMAIL PROTECTED]>: > It strikes me that the JMS client must be sending the persistent non > transacted messages non blocking. I.e. it is sending the next one without > waiting for confirmation from the server that the last one has been > persisted (which involves a network round trip).
Yes, you are correct. > If JMS semantics are to be followed, then the JMS client must wait for such > confirmation before sending the next one (in the same way as it must wait > for commit to hit the server and a response to be received). No, the JMS specification does not mandate this. However I agree this is annoying (it is a result of the behaviour of the underlying AMQP protocol version implemented by Qpid M2, since publish is not a synchronous operation). I believe that the later version of the protocol can support proper guaranteed delivery without requiring transactions - maybe someone who worked on the M3 Java client can let us know whether it supports both modes? RG
