"ovidiu.feodorov(a)jboss.com" wrote : | I don't think that methods that return a non-void result need arguing (with the exception of MessageCallbackHandler.handleMessage(), which I will talk about later). They represent round-trips to the server, and they are invoked because the client needs something from the server. The client cannot continue unless it has the reply it needs, so trying to suggest to replace these with asynchronous calls just for the sake of it seems to me at least questionable | | Now let's analyze the methods that don't return anything, but represent life-cycle operations, and rarely used mutators (ConnectionEndpoint's start(), stop(), close(), closing(), setClientID(), SessionEndpoint's addTemporaryDestination(), deleteTemporaryDestination(), unsubscribe(), close(), closing(), ConsumerEndpoint's close() and closing()). How many times a second do you start, stop or close connections? Or how many times a second do you add or delete temporary destinations. These are life cycle methods (we use DEBUG to log them), why would they need to be optimized for speed, when reliability and the convenience of getting the acknowledgment of their successful completion (or not) are much more important? Optimizing these operation do not improve message throughput, which is in the end all that matters. | | ConnectionEnpoint.sendTransaction(). When your transaction successfully completes on the server (or, more importantly, when it does not), your client wants to know. Using an RPC style invocation makes propagating exceptions back easy. The alternative would be to asynchronously send the "transaction" and then somehow listen for a confirmation (positive or negative). What would be the benefit of doing that? | | SessionEndpoint.send(). See the previous "correct approach" discussion. If you don't invoke this method synchronously, how does the client know that the message has been accepted by the broker? | | SessionEndpoint.cancelDeliveries(). This is used to cancel any undelivered messages left in the client buffer when the consumer is closed or to cancel any messages that couldn't be redelivered locally at session recovery. Both cases are extraordinary events that do not impact message throughput performance in any way. | | This leaves us SessionEndpoint.acknowledgeBatch(), SessionEnpoint.acknoweldge() and ConsumerEndpoint.more() that can arguably improve the throughput if they're made asynchronous. Also, sending the message to the client for delivery is a good candidate for asynchronicity. | | So, getting back to what you said, "In many cases with messaging we don't want RPC (in some cases we do).", I would actually say that in many cases with messaging we want RPC, and is some very special cases we don't. | | Remoting should support both modes, and we should choose carefully how we use them. | To cut a long story short, of course many operations need to be synchronous, this is not in contention. However most of the operations (with the exception of send) on the primary execution paths can probably be done asynchronously. These are the ones that need to be fast, they include: Sending messages from server=>client Flow control messages (currently just more()) but we will need to extend this probably. Acknowledgements (I am pretty sure but not 100% about this one - it needs more thought) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979329#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...