[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Incorporating Remoting http transport into Messaging

OK, so let's think about this a little bit. In the old version, the server-side executor thread would put the message(s) on the wire and WAIT all the time until the messages make it to the MessageCallbackHandler and a reply to that RPC (in the form of a MessagingMarshallable instance) is sent back to the server. In the new version, the server-side executor thread just hands the messages over to Remoting, in the form of a Callback instance and returns immediately. Long time after that, when messages make it to the client, the client asynchronously sends a delivery confirmation, that says it actually received the messages (this is, again, NOT the client acknowledgment). The server actually uses that information (the number of in-flight messages) only in a special use case, when the consumer is stopped, so contending on the lock that protects it is done in the context of a life cycle (i.e. very slow) event. So, no, the modification doesn't negatively affect the throughput, it actually improves it, if anything. As for the argument that this behavior is needed only for the HTTP transport, that is not true. It is needed for any transport. Remember that even for TCP, we want "truly" asynchronous "invocations". The combination of new Remoting API and changed ServerConsumerEndpoint/MessageCallbackHandler behavior makes it transparent to the transport. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988255#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...