"ovidiu.feodorov(a)jboss.com" wrote : | Your "correct" approach raises the following issue: | | Assume that you want to write a client that needs guaranteed delivery on a queue. You write that client to create a persistent message and send the message by invoking a producer's send() method. As soon as your send() method returns without an exception, this is a hard guarantee to your client that the messaging broker accepted the message for further delivery. You cannot have that guarantee without you call actually reaching the server. At that point, the client can call System.exit() and go to the client's heaven, fully assured that his message is being taken care of. If you use the asynchronous approach you describe, the client will be never able to rely on this guarantee. | When I was talking about flow control previously I was specifically talking about pushing messages from server -> consumer, not sending messages from client -> server. For pushing from server->client, for the reasons already stated (latency problems) an RPC model will ruin performance. For sending from client to server, yes you are correct in stating this must be RPC, for JMS at least, although AMQP is less strict on this and allows asynchronous send I believe. (Also bear in mind, that an absence of an exception does imply success, but the presence of an exception does not imply failure - the message could actually have been added to the queue - but this is not particularly relevant to the discussion). So, for JMS, to maximise sending throughput for a high latency network would be done on the application level by sending messages in transactions with multiple messages per transaction. This allows many messages to be sent in one RPC. anonymous wrote : | I disagree with a). An RPC model is very convenient when dealing with life cycle operations such as creating connections, sessions, producer, consumer, browsers, etc. It's a very convenient model for a high granularity reliable operations. | Let's be clear on this. I am not advocating an all or nothing asynchronous approach. Of course some operations need to be synchronous. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979320#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...