"timfox" wrote : | IMHO the R2 socket protocol suffered from fundamental design flaws and trying to copy them in R3 means copying those flaws too... ? | The other day we watched a documentary on HBO about great boxers of the twentieth century. There was some amazing footage of Jack Dempsey and Gene Tunney, probably well into their sixties, meeting in formal evening clothes and sparring in a ring. They pretended to throw some punches, and, after a little while, they grabbed each other and started ballroom dancing. It was very sweet. Talking about the incompatibilities between JBossRemoting and JBossMessaging reminds me of two old boxers, meeting one more time. :-) What Tim calls "design flaws" I would call "design decisions". The fact is that the socket transport was derived from the PooledInvoker, which was meant to support EJBs and a remote method invocation model. And EJB/EJB3 + Remoting just works. In two and a half years, I recall making exactly one change in Remoting on behalf of EJBs. JBM + JBR, on the other hand, has always been a more difficult fit. A lot of work has been done, on both sides, to make it work, and I'm very happy that JBM 1 has been successful. I'm also relieved that JBM 2 will have a more appropriate foundation. "trustin" wrote : | The socket and bisocket transport will run on XNIO / Netty. It's to make sure that R2 clients can talk to R3 services. It doesn't mean we are going to retain the old socket I/O code. | Correct me if I'm wrong, but I was under the impression that, for a moderate number of worker threads, the old style blocking model outperforms NIO. If so, I would argue that, not only does it make sense to implement a new version of the socket transport, but it also makes sense to preserve the old version as well. So, Tim, do you want to be Dempsey or Tunney? :-) -Ron View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167209#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...