[jboss-dev-forums] [Design of JBoss Remoting, Unified Invokers] - Re: R3 transports to implement

[timfox]

If you want to support the R2 protocol that's going to force you to implement things in a certain R2 way.

The main problem with the R2 design is that it has no strong relation between the user connection object (the Client object) and the actual underlying connection used, e.g the TCP connection in the case of the socket transport.

This means that subsequent invocations on the same Client object can actually end up using different TCP connections since there's a client side pooling mechanism. Consequently you can end up with situations where later invocations overtake earlier invocations since they're using different connections - ordering is lost. We had to do various nasty hacks to workaround this problem in JBM.

The R2 protocol also assumes a request has exclusive use of a connection until it gets a response back. I.e. get connection from pool, write request, wait for response, return connection to pool.

This also leads to scalability and latency issues and ends up with large numbers of TCP connections created when you have a lot of concurrent requests.

A sensible implementation would have allowed many requests and responses to be interleaved on the same connection - identifying each request/response with some identifier on the wire. Since R2 does not write any such id with the request, - it doesn't need to since it assumes exclusive use of the connection, then if you were to provide R2 protocol support you would also have to implement the same exclusive connection use and client pooling in R2 - do you really want to do that?

My advice would be not to try and provide compatibility with R2 in R3. It'll just force you into implementing the same broken model, and drag you into a nightmare - R2 was broken - make a clean start!

IMHO if people really want to run R2 they should just use the R2 service - nothing's stopping them just running the R2 service on the server if that's what they want to do.

Also, it's normally fine to drop compatibility on major version releases. E.g. JBM 1.x is not compatible with JBM 2.0. That's normal practice.

Just my 2c



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

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