[jboss-dev-forums] [Design of Clustering on JBoss (Clusters/JBoss)] - Re: Solution of JBREM-954 and ramifications into UnifiedInvo
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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...