[jboss-jira] [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException

[Galder Zamarreno (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12408634 ] 
            
Galder Zamarreno commented on JBREM-954:
----------------------------------------

Re: Does all of this workaround stuff go away if Remoting just re-throws the InterruptedException?

Possibly from the point of view of Remoting, but on the AS side, it would be thrown back as it is 
which would be a problem because IE is a checked exception, iow, you need to declare it, 
otherwise you get an UndeclaredThrowableException . So, we might need a bit of laundering on the AS 
side. I hope to start a design forum thread in both cluster design and remoting design on this topic.

Re: I could change MicroSocketClientInvoker.handleException() to re-throw InterruptedExceptions

Right now, this looks to me the most reasonable thing to do from Remoting's perspective.

Re: To avoid breaking any code, I think I would make it a configurable option to re-throw 
InterruptedExceptions and leave the current behavior as the default.

Hmmmm, not 100% sure. Semantically, converting an IE into a CannotConnectException seems buggy 
to me.

Let's discuss this in the forum thread I'll start in the next couple of days.

> InterruptedException should not be rethrown as CannotConnectionException
> ------------------------------------------------------------------------
>
>                 Key: JBREM-954
>                 URL: http://jira.jboss.com/jira/browse/JBREM-954
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.2.2.SP4, 2.2.2.SP7
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: 2.2.2.SP8
>
>         Attachments: MicroSocketClientInvokerTest.java
>
>
> Let's say you have a Swing GUI application that calls an EJB remotely and the 
> client code is waiting to get entry to client side pool (controlled by clientMaxPoolSize). 
> While waiting, the user decides to cancel the operation by interrupting the thread. In 
> that case, the Remoting code does not make a difference between an InterruptedException 
> and any other Exception:
> MicroSocketClientInvoker.java:
> protected SocketWrapper getConnection(Marshaller marshaller,
>                                          UnMarshaller unmarshaller,
>                                          int timeAllowed)
>    throws Exception
> {
>    long start = System.currentTimeMillis();
>    long timeToWait = (timeAllowed > 0) ? timeAllowed : 30000;
>    boolean timedout = !semaphore.attempt(timeToWait);
> Any Exception thrown from getConnection() is treated as a CannotConnectException
>          try
>          {
>             socketWrapper = getConnection(marshaller, unmarshaller, timeLeft);
>          }
>          catch (Exception e)
>          {
> //            if (bailOut)
> //               return null;
>             semaphore.release();
>             if (trace) log.trace(this + " released semaphore: " + semaphore.permits());
>             throw new CannotConnectException(
>                "Can not get connection to server. Problem establishing " +
>                "socket connection for " + locator, e);
>          }
> The EJB3 layer wraps this in CannotConnectException in a RuntimeException like:
> throw new RuntimeException("cluster invocation failed, last exception was: ", lastException);
> This is misleading on the Remoting side. Semantically, the fact that the thread attempting 
> to connect is interrupted shouldn't be translated into a CannotConnectException.
> Please find attached a test case I've created.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira