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

[david.lloyd@jboss.com]

"trustin" wrote : I talked to Tim in the JBoss Messaging IRC channel to get some quick answers about the flaws of R2 protocol.  They were:
  | 
  |  * Connection pooling doesn't allow you to send other commands when a request is in progress.  It also causes the order of invocation get mixed up. - This issue can be fixed by fixing R3 client behavior.

Correct.

"trustin" wrote : * The way ping works - I don't have much idea about how ping works.  Someone could address this issue.
  | 
  |  * Protocol doesn't have a command type identifier - It's OK because we can bump up the version field and provide a command type identifier, sequence no, etc if necessary.

If these issues are a problem, then don't use the R2 protocol.

"trustin" wrote : Also, he suggested me to abandon R2 protocol and go straight to the whole new transport (e.g. SSH + new wireformat) because:
  | 
  |  * We are not required to be backward compatible with R2 and we should give it up to avoid maintenance difficulty.

Incorrect, we are in fact required to be compatible with R2 before R3 can be accepted into JBossAS.

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


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

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