[jboss-remoting-issues] [JBoss JIRA] Closed: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
Ron Sigal (JIRA)
jira-events at lists.jboss.org
Fri Jun 20 03:06:37 EDT 2008
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Ron Sigal closed JBREM-954.
---------------------------
Resolution: Done
"I think you can release having run your tests." - Galder.
> 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
More information about the jboss-remoting-issues
mailing list