[jboss-remoting-issues] [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_12407101 ] 
            
Galder Zamarreno commented on JBREM-954:
----------------------------------------

There's a nasty side effect associated with this JIRA. Both UnifiedInvokerHAProxy, 
in the case of EJB2s and ClusterChooserInterceptor in the case of EJB3s would 
remove the target node from the family upon a CannotConnectException, potentially 
making service unavailable for example if that node was the only one left in the cluster.

The only safe way to recover from this would be to get the proxy again from JNDI or from 
home.create() in the case of EJB2.

The customer encountering this suggested putting an interceptor in between ClusterChooserInterceptor
and InvokeRemoteInterceptor that would follow the current workaround and pass up a different
Exception, such as InterruptedException. In the case at least of EJB3, this would work fine as CCI
would throw back the InterruptedException without touching the family. The IE would probably come 
wrapped around a RE but would work fine. I hope the customer can upload the interceptor if he decides
to create it.

I'll talk about EJB2 in the next comment.

> 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