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

[Galder Zamarreno (JIRA)]

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

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

    Workaround Description: 
Any workaround cannot simply just rely on the client side checking 
the Exception thrown because both UnifiedInvokerHAProxy and 
ClusterChooserInterceptor remove nodes from the cluster family upon 
a CannotConnectException.

So, there needs to be an Exception laundering phase in between the 
invoker proxy/interceptor and Remoting. In the case of EJB3, this can be 
done adding an interceptor in between ClusterChooserInterceptor and 
InvokeRemoteInterceptor.

The laundering would involve getting the CannotConnectException and 
checking whether the cause is InterruptedException and if so, rethrow the 
InterruptedException only.

In the case of EJB2, there's no gap to add an interceptor to do the 
laundering. The logic cannot be put into a different invocation marshaller 
either because it gets called after getting the connection.

  was:
By using getCause() on the Exception propagated, the client code could 
discover that the root Exception was an InterruptedException:

RuntimeException.getCause() would return CannotConnectException
CannotConnectException.getCause() would return InterruptedException


> 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: Ron Sigal
>             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