Tim wrote : | In many cases with messaging we don't want RPC (in some cases we do). | This is a table that contains ALL client-to-server interactions, represented as metod signatures. | Method Name Return Value | ConnectionFactoryEndpoint | createConnectionDelegate() ConnectionDelegate | getClientAOPConfig() byte[] | getIdBlock() IdBlock | ConnectionEndpoint | createSessionDelegate() SessionDelegate | getClientID() String | getPreparedTransactions() Xid[] | isClosed() boolean | setClientID() - | start() - | stop() - | sendTransaction() - | close() - | closing() - | SessionEndpoint | createConsumerDelegate() ConsumerDelegate | createBrowserDelegate() BrowserDelegate | createQueue() JBossQueue | createTopic() JBossTopic | isClosed() boolean | acknowledgeBatch() - | acknowledge() - | addTemporaryDestination() - | deleteTemporaryDestination()- | unsubscribe() - | send() - | cancelDeliveries() - | close() - | closing() - | ConsumerEndpoint | isClosed() boolean | more() - | close() - | closing() - | BrowserEndpoint | nextMessage() Message | hasNextMessage() boolean | nextMessageBlock() Message[] | | This table lists server-to-client interactions. | Method Name Return Value | | MessageCallbackHandler handleMessage() HandleMessageResponse | | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979228#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...