[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-955) CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException

[Ron Sigal (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-955?page=comments#action_12410666 ] 
            
Ron Sigal commented on JBREM-955:
---------------------------------

Galder's attached test is on the 2.x branch as org.jboss.test.remoting.transport.socket.interrupt.MockInvokerInterruptTestCase.

> CLONE [JBREM-954] - InterruptException should not be rethrown as CannotConnectionException
> ------------------------------------------------------------------------------------------
>
>                 Key: JBREM-955
>                 URL: http://jira.jboss.com/jira/browse/JBREM-955
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.4.0.CR1 (Pinto)
>            Reporter: Galder Zamarreno
>         Assigned To: Ron Sigal
>             Fix For: 2.4.0.CR2
>
>
> 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