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

[Galder Zamarreno (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]

Galder Zamarreno updated JBREM-954:
-----------------------------------

    Attachment: MicroSocketClientInvokerTest.java

> InterruptException 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
>            Reporter: Galder Zamarreno
>         Assigned To: Ron Sigal
>             Fix For: 2.2.2.SP4
>
>         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