[
http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12408634 ]
Galder Zamarreno commented on JBREM-954:
----------------------------------------
Re: Does all of this workaround stuff go away if Remoting just re-throws the
InterruptedException?
Possibly from the point of view of Remoting, but on the AS side, it would be thrown back
as it is
which would be a problem because IE is a checked exception, iow, you need to declare it,
otherwise you get an UndeclaredThrowableException . So, we might need a bit of laundering
on the AS
side. I hope to start a design forum thread in both cluster design and remoting design on
this topic.
Re: I could change MicroSocketClientInvoker.handleException() to re-throw
InterruptedExceptions
Right now, this looks to me the most reasonable thing to do from Remoting's
perspective.
Re: To avoid breaking any code, I think I would make it a configurable option to re-throw
InterruptedExceptions and leave the current behavior as the default.
Hmmmm, not 100% sure. Semantically, converting an IE into a CannotConnectException seems
buggy
to me.
Let's discuss this in the forum thread I'll start in the next couple of days.
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: Galder Zamarreno
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