[ron_sigal]

"trustin" wrote:

We can run both R2 and R3 at the same time in the microkernel, so R2 users should be able to keep using R2 services or upgrade to R3.

This is true; however then we will have not only both versions running, but all services will have to have an R2 and R3 version. This might be difficult to do in some cases where the Remoting implementation is tied to the service (like the UnifiedInvoker for example).

Not that I want to rule this out mind you. I'm just expressing that this difficulty does exist.

For an EJB3 in AS 5 to be accessible from both AS 4.2 and AS 5, then

1a. either, as David says, there would have to be two EJB3 implementations running on the server, or

1b. we would have to turn org.jboss.aspects.remoting.AOPRemotingInvocationHandler into a bean that could be shared by both Remoting 2 and Remoting 3,

and

2a. either EJB3 would have to create two separate proxies, or

2b. org.jboss.aspects.remoting.InvokeRemoteInterceptor would have to be able to talk to both Remoting 2 and Remoting 3, which means

2ba. either it would have to probe its environment to determine which version of Remoting is available (could be a System property), or

2bb. we would have to provide a Remoting 2 facade for Remoting 3 so that InvokeRemoteInterceptor doesn't need to know which version of Remoting is running.

As for 1, would having two implementations of the same SFSB running simultaneously cause a problem? 2a seems distasteful. As for 2ba versus 2bb, that's a separate issue. Having a Remoting 2 facade would be *nice*, but maybe not urgent.

For me, the overriding consideration is that all of these changes, while seemingly doable, amount to spreading all over the Application Server something that should be handled discreetly in Remoting.

1a+2a is particularly egregious in this respect. I think we could live with 1b+2ba, since org.jboss.aspects.remoting is part of the integration of Remoting into the Application Server. I would say that

1. 1b+2ba should be our minimal goal, and

2. hiding everything inside Remoting proper is preferable, since it better serves standalone users.

The latter seems to imply a "socket" transport in Remoting 3.

[ron_sigal]

"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

[ron_sigal]

"trustin" wrote:

I think we can make the XNIO-based protocol implementation look similar to that of Remoting 2 socket transport. As David explained in the IRC channel, we could simply retain the core classes which are serialized and deserialized in R2 and convert them to R3 classes and vice versa to implement R2 compatibility:

There's also the non-invocation protocol elements to worry about. That is, in addition to ordinary invocations, org.jboss.remoting.ServerInvoker handles connection monitoring, callbacks, and streaming.

But Tim gives me an idea. To my knowledge (and Scott can correct me if I'm wrong :-) ), JBossMessaging is the only JBoss project that uses leasing and callbacks. And since JBM 1 (which lives in EAP 4.2) and JBM 2 (which I assume will live in EAP 5) are not compatible, the need to support these features in the Remoting 2 <-> Remoting 3 compatibility solution plummets in urgency.

[trustin]

"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.

I thought XNIO provides a blocking transport?

[trustin]

For an EJB3 in AS 5 to be accessible from both AS 4.2 and AS 5, then

1a. either, as David says, there would have to be two EJB3 implementations running on the server, or

1b. we would have to turn org.jboss.aspects.remoting.AOPRemotingInvocationHandler into a bean that could be shared by both Remoting 2 and Remoting 3,

I'm not following this. Could you explain a little bit further? Regarding 1a, I thought what we need to do is to run two Remoting versions (2 and 3) which calls local EJB3?

[ron_sigal]

"trustin" wrote:

I'm not following this. Could you explain a little bit further? Regarding 1a, I thought what we need to do is to run two Remoting versions (2 and 3) which calls local EJB3?

I didn't express myself well. I meant that for Remoting 2, calls on an EJB3 would go to AOPRemotingInvocationHandler, and for Remoting 3, they would go to something new, an "AOPRemotingRequestListener", maybe. Of course the EJB3 code itself would be the same. But there would be two paths to the same EJB3.

[trustin]

1. 1b+2ba should be our minimal goal, and

2. hiding everything inside Remoting proper is preferable, since it better serves standalone users.

The latter seems to imply a "socket" transport in Remoting 3.

The 'socket' transport here is the R2-compatible transport rather than the backward incompatible R3 socket transport, right?

[ron_sigal]

"trustin" wrote:

The 'socket' transport here is the R2-compatible transport rather than the backward incompatible R3 socket transport, right?

Rignt.

[dmlloyd]

2bb. we would have to provide a Remoting 2 facade for Remoting 3 so that InvokeRemoteInterceptor doesn't need to know which version of Remoting is running.

A "2bc." could be to go with the original plan to provide a Remoting 3 facade for Remoting 2 invocations. Then the invoker client would simply always use Remoting 3 and it use the service discovery mechanism to figure out how the request moves across the wire.

A similar thing could be done on the server side: create an emulation service that receives invocations and forwards them to a Remoting 3 RequestHandler.