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

Wed Oct 18 00:03:30 EDT 2006

1. Messaging needs a working multiplexed transport. 

There is currently a multiplex transport (as Ovidiu noted) and how it works under the hood is explained at (http://labs.jboss.com/portal/jbossremoting/docs/multiplex/multiplex.html).  Its performance is not great (see http://labs.jboss.com/portal/jbossremoting/docs/benchmark/performance_benchmark.html for comparison benchmarks).  Ron can probably 

I have been looking at Mladen's MUX project as another option for a multiplex transport to remoting.  However, it does not automatically handle calling back over the same physical connection, so this behavior will need to either be added within the MUX project or on top of it.  I have not done much testing with the MUX project other than some simple coding to see how it works/behaves.  No idea on performance, but know that Mladen says he still wants some more time to work on it before he feel comfortable doing a GA release for it.

2. Remoting uses a server-side blocking thread-per-connection model. 

So guess would be good to cover scenarios and best approaches for them.  The first scenario would be having a limited set (in the low hundreds) of clients that each regularly make invocations.  In this scenario, having optimal throughput is probably the desired behavior and the current remoting code is designed for this.  At the other end of the spectrum would be having a large number of clients (in the thousands) that each make periodic requests (meaning is not in tight loop that continually makes invocations).  The best scenario for this is to use non-blocking i/o.  The main reason for this is if use blocking i/o (besides running out of resources) will have thread per request and will be slow as balls because of all the thread context switching for all the concurrent requests.  Then there are the scenarios in between (btw can add config so that remoting does not hold connection after invocation on the server side so that will free worker threads faster, which I am pretty sure is already in jira).

As Ovidiu said, I am looking into adding NIO (and APR) currently.  However, I don't want anyone thinking that will see a performance gain from the NIO transport until reach a certain threshold of clients (probably somewhere between 300-700, but don't have anything concrete on this yet).  Of course, there are still a ton a factors that influence this as well such as number of cpus, jvm, network, etc.  

3. Remoting uses a client-side blocking request-response invocation model.

Have made the code changes (for jira issue http://jira.jboss.com/jira/browse/JBREM-548) so that if doing one-way invocations, only the request ever gets written to the wire and that thread on the client returns immediately after the write.  On the server side, it never writes the response back to client.

Probably good to have better definition of what asynchronous means.  There are a lot of places the term can be used.  At a high level in the call stack, can just mean using a future model to make call and wait for a response to come back at later point in time (or just a callback on a different thread at later point in time). At lowest level, could be talking about only writing on the wire and not waiting for response off the wire.  Lots of places term can be used in between the high and low level.

4. Messaging needs the ability to send unformatted data on the wire. 

It is possible to send and receive raw payload data using remoting where is not wrapped in the remoting InvocationRequest/InvocationResponse using configuration per request.  However, the behavior of doing this is not consistent over all the current transports.  Also, sending raw data will prevent a lot of the extra remoting features from being used as internal remoting metadata is included in the InvocationRequest/InvocationResponse wrappers.  

Another issue is the types of streams being given to the marshalling layer being inconsistent across the different transports (this is covered in http://jira.jboss.com/jira/browse/JBREM-597).  My preference is to only send the raw OutputStream/InputStream to the marshalling layer and allow the Marshaller/UnMarshaller implementations decide on what type of streams to wrap around the raw ones passed in (if any).  

There is certainly a lot of re-working that can be done in this general area and hoping the efforts for NIO transport will help bring these out.  

As for AMQP, I don't now anything about it, so can?t comment.

As for remoting and its purpose, it is exactly as Juha stated which is to provide a remoting platform that other JEMS projects can use (but imo should be by choice).  I have tried my best to do this in a way that any new feature or implementation does not negatively impact any other project that may be using remoting.  The only jira issue derived from the messaging project that has been rejected is http://jira.jboss.com/jira/browse/JBREM-371, which I couldn't do per previous sentence.  It is my guess that at least a third of the development effort for remoting this year has been related to supporting the messaging project (which has all been good for the remoting project in general).  The remoting team is myself and Ron Sigal (who is now splitting development time between remoting and messaging).  There are 51 remaining open issues for the next remoting release (plus many external ones related to remoting).  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978948#3978948

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