[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Messaging and Remoting

This is yet another discussion thread on the subject of Messaging/Remoting integration. The previous one (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971228) ended nowhere. What is different about the current one is that I will manage it until we reach conclusions on all points in contention. We need to take a decision fast, since the remoting problem is a dependency of everything else in 1.2.Beta. In practical terms, we need to decide if is feasible to extend JBoss Remoting in a way that helps Messaging to reach its functionality and performance targets, or replace it with a specialized Messaging transport layer, independent of JBoss Remoting. This is the list of points of contention: 1. Messaging needs a working multiplexed transport. This is documented by the JIRA issue http://jira.jboss.org/jira/browse/JBMESSAGING-92. We want to use the same physical TCP/IP connection to send data from client to server AND asynchronously, from server to client. Once this is available, the client won't need to create its physical callback server anymore. Callback servers cannot be used in firewalled environments, and even in common LAN environments they are liable to introduce complications. Support for multiplexed invokers exists in JBoss Remoting (http://labs.jboss.com/portal/jbossremoting/docs/guide/ch10.html#d0e5713). Tim worked on integrating it to a certain point, and then he stopped on account of performance issues, if I remember correctly. It would be interesting if he shares his conclusions here, so all of us understand what didn't work. 2. Remoting uses a server-side blocking thread-per-connection model. The ServerInvoker has a bounded "ServerThread"s thread pool, the number of simultaneous invocations that can be handled at a time is limited by invoker's maxPoolSize configuration parameter. Once a "ServerThread" is allocated to a client connection, it will stay associated to that connection until the client closes the socket or a socket timeout occurs.This could lead to thread starvation in presence of a large number of clients. Increasing the number of server threads will draw down the performance because the large number of context switches. A non-blocking NIO model would probably more appropriate here. Other messaging projects use this approach already. I know that Tom is working on adding NIO support to Remoting, and maybe this is all we need. It would be nice if can share his thoughts on the subject here. 3. Remoting uses a client-side blocking request-response invocation model. Remoting is essentially a mechanism through which a client sends an invocation over the network and blocks waiting the response. This is not always what Messaging needs. Messaging clients should be able to send data on the wire without the unnecessarily added burden of waiting for a reply. Similarly, the server should be able to asynchronously send data to the client. Remoting simulates this situation by using a client-side worker thread that blocks instead of the calling thread, and throwing away the server response. A variation of this mechanism uses a server-side pooled asynchronous processing threads that throws away the response on the server. The common theme here is "throwing away" the reply. We are wondering what would it take to amend Remoting API (and implementation) to support pure asynchronous client calls. 4. Messaging needs the ability to send unformatted data on the wire. This is required to support AMQP. Remoting wraps everything in Invocation Request instances. Personally I think that adding the functionality we need (inside or outside of Remoting), instead of replacing Remoting altogether is the most efficient way to go forward. If we go for a new implementation, we need to add by ourselves functionality that comes for free in Remoting, such as: * Connection failure notification and leasing/pinging * Automatic local invocation optimization (pass by reference) * Pluggable transports, specifically HTTP(S) and SSL. * Versioning support (however, this actually may prove to be a problem, in what AMQP support is concerned). Opinions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978910#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...