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

[ron.sigal@jboss.com]

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?

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

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?

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

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