[JBoss JIRA] Created: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException
5:13 a.m.
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
Fix For: 2.2.2.SP4
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
5:13 a.m.
New subject: [JBoss JIRA] Assigned: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Galder Zamarreno reassigned JBREM-954:
--------------------------------------
Assignee: Ron Sigal
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
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
5:14 a.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException
[ 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
4:46 p.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Ron Sigal updated JBREM-954:
----------------------------
Fix Version/s: 2.2.2.SP8
(was: 2.2.2.SP4)
Affects Version/s: 2.2.2.SP4
2.2.2.SP7
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
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
1:36 p.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Galder Zamarreno updated JBREM-954:
-----------------------------------
Summary: InterruptedException should not be rethrown as CannotConnectionException
(was: InterruptException should not be rethrown as CannotConnectionException)
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
1:40 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12406944 ]
Galder Zamarreno commented on JBREM-954:
----------------------------------------
TODO: If Remoting ends up propagating back IE or throwing
a different Exception, create a JIRA to investigate whether
the UnifiedInvokerHAProxy should react differently to such
situation, i.e. allow failover in those situations if no transaction
#was started.
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
11:12 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12407094 ]
Galder Zamarreno commented on JBREM-954:
----------------------------------------
TODO2: Same as 1st TODO but for EJB3 with
ClusterChooseInterceptor
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
11:52 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ 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
11:59 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12407103 ]
Galder Zamarreno commented on JBREM-954:
----------------------------------------
In the case of EJB2 and UnifiedInvokerHAProxy, it should be fine as
well cos if:
response = clientInstance.invoke(invocation, null);
throws an InterruptedException, it'd be catched by:
catch(Throwable throwable)
{
log.debug("Invocation failed: " + throwable, throwable);
// this is somewhat of a hack as remoting throws throwable,
// so will let Exception types bubble up, but if Throwable type,
// then have to wrap in new Exception, as this is the signature
// of this invoke method.
if(throwable instanceof Exception)
{
throw (Exception) throwable;
}
throw new Exception(throwable);
}
So, would be rethrown but without affecting the cluster family formation.
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
12:05 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12407106 ]
Galder Zamarreno commented on JBREM-954:
----------------------------------------
Actually, in the case of EJB2, because all this logic happens in
the proxy itself, there's no chance of putting something in
between the proxy itself and Remoting.
In EJB3, because the failover and cluster family update logic
happens in ClusterChooserInterceptor, you can put an interceptor
in between ClusterChooserInterceptor and InvokeRemoteInterceptor.
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
12:11 p.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ 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
12:19 p.m.
New subject: [JBoss JIRA] Assigned: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Galder Zamarreno reassigned JBREM-954:
--------------------------------------
Assignee: Galder Zamarreno (was: Ron Sigal)
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
6:04 a.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ 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. Note: if the EJB3 called does not declare
Exception or InterruptedException in its method signature, the client would
get a java.lang.reflect.UndeclaredThrowableException wrapping the IE. In
that case, either make the client cope with UndeclaredThrowableException or
in the laundering interceptor, wrap the IE with a RuntimeException.
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:
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.
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
10:56 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12408405 ]
Ron Sigal commented on JBREM-954:
---------------------------------
Hi Galder,
I'm sorry I haven't followed this issue more closely.
Does all of this workaround stuff go away if Remoting just re-throws the
InterruptedException? I could change MicroSocketClientInvoker.handleException() to
re-throw InterruptedExceptions and create a 2.2.2.SP8-preview jboss-remoting.jar. 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.
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
10:57 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ 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
6:33 a.m.
New subject: [JBoss JIRA] Work started: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Work on JBREM-954 started by Galder Zamarreno.
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
6:51 a.m.
New subject: [JBoss JIRA] Updated: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Galder Zamarreno updated JBREM-954:
-----------------------------------
JBoss Forum Reference:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134185
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
2:50 a.m.
New subject: [JBoss JIRA] Assigned: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Galder Zamarreno reassigned JBREM-954:
--------------------------------------
Assignee: Ron Sigal (was: Galder Zamarreno)
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
2:50 a.m.
New subject: [JBoss JIRA] Work stopped: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=all ]
Work on JBREM-954 stopped by Galder Zamarreno.
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
9:11 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12416182 ]
Ron Sigal commented on JBREM-954:
---------------------------------
The changes to org.jboss.remoting.transport.socket.MicroSocketClientInvoker and
SocketClientInvoker, described in JBREM-955, have been applied to the 2.2 branch, and the
test cases
* org.jboss.test.remoting.transport.socket.interrupt.InterruptedExceptionTestCase
* org.jboss.test.remoting.transport.socket.interrupt.MockInvokerInterruptTestCase
have been committed.
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
1:20 a.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12416187 ]
Ron Sigal commented on JBREM-954:
---------------------------------
Forgot that I was going to make the new behavior configurable but not default. WIll
update MicroSocketClientInvoker and SocketClientInvoker accordingly.
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
10:19 p.m.
New subject: [JBoss JIRA] Commented: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ http://jira.jboss.com/jira/browse/JBREM-954?page=comments#action_12416380 ]
Ron Sigal commented on JBREM-954:
---------------------------------
The wrapping behavior is now configurable. To turn on wrapping, set
MicroSocketClientInvoker.WRAP_INTERRUPTED_EXCEPTION (actual value
"wrapInterruptedException") to "true" in InvokerLocator or
configuration map.
Updated
* org.jboss.test.remoting.transport.socket.interrupt.InterruptedExceptionTestCase
* org.jboss.test.remoting.transport.socket.interrupt.MockInvokerInterruptTestCase
to account for both behaviors: wrapping and not wrapping.
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
2:06 a.m.
New subject: [JBoss JIRA] Closed: (JBREM-954) InterruptedException should not be rethrown as CannotConnectionException
[ 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
5803
days inactive
5884
days old
jboss-remoting-issues@lists.jboss.org
22 comments
2 participants
participants (2)
-
Galder Zamarreno (JIRA) -
Ron Sigal (JIRA)