[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo

[galder.zamarreno@jboss.com]

"ron.sigal at jboss.com" wrote : I'm going to regurgitate all of this just to verify that I understand the issues.
  | 
  | 1. We don't want Remoting turning an InterruptedException into a CannotConnectException because that has a negative effect in a clustered context.
  | 
  | 2. We don't want Remoting rethrowing an InterruptedException because that could result in the application code getting an UndeclaredThrowableException.
  | 
  | So, we want to wrap the InterruptedException in something, other than a CannotConnectException, that will not result in an UndeclaredThrowableException .
  | Is that the kernel of the matter, so far?

Yeah

"ron.sigal at jboss.com" wrote : From the point of Remoting, I agree that the current situation is misleading, but I'm slightly uncomfortable adding a RuntimeException to the API.  UnitedInvokerProxy and UnitedInvokerHAProxy are controlled by JBoss, so we can handle any API changes, but for standalone Remoting users, we would be springing on them a stealth change in the API.  

Client.invoke() is the interface Unified invokers and others deal with and this method throws Throwable so your users have to be prepared for anything anyway... In fact, the return value of Client.invoke() can even be an Exception...

"ron.sigal at jboss.com" wrote : Here's an alternative proposal.  Remoting could turn an InterruptedException into an InterruptedIOException, which is a subclass of IOException.  
  | 
  | 1. You could argue that it's still an API change, but MicroSocketClientInvoker.transport() already declares that it throws an IOException, so it's just adding an IOException with a different message.
  | 
  | 2. Isn't it likely that application code, EJB or otherwise, already catches and copes with IOExceptions?
  | 
  | Well, I guess you could argue that an IOException would be unexpected in the case of a local EJB. 
  | 
  | I'm torn.
  | 
  | WDYT?

In EJB2, methods in remote business/home interfaces had to declare java.rmi.RemoteException, which is a subclass java.io.IOException, so your trick would work fine there.

In EJB3 this is not a requirement though. "The methods of the business interface may only throw the java.rmi.RemoteException if the interface extends java.rmi.Remote.". You can still have remote business interfaces ala EJB 2.x, but not a requirement. Just annotate your business method as @Remote and done. So, in the EJB3 world, there's a strong possibility of getting a UndeclaredThrowableException. Then again, in an EJB3 world, if you have a business interface which is gonna be Remote, I'm sure you'll declare that it can throw some kind of Exception, otherwise any IOExceptions would blow as UndeclaredThrowableException.

By the way, how would you turn InterruptedException into an InterruptedIOException? You can't set a cause Throwable to InterruptedIOException, so you can't really wrap IE around a InterruptedIOException,

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

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