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

[bill.burke@jboss.com]

anonymous wrote : 
  | 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.
  | 

Basically, my thoughts on multiplexing are that it is good for certain usecases bad for others.  For instance, many remote clients do not have more than one thread talking to the server.  While a web application might have many threads talking to one remote JMS server (HA JMS?)  At what point does it make sense to multiplex on the client side? What point does it make sense to multiplex on the server side?

The largest overhead and performance drain is in creating connections.  IIRC, Tom took a lot from the PooledInvoker design which I wrote.  The PooledInvoker was written in mind of a long running client that needs to continuously talk to the server and avoid creating new connections.

I think you should make a few prototypes and bench.  Maybe the Tomcat guys have a lot of insight into this?

Bill





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=3978919#3978919

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978919