]
Ron Sigal commented on JBREM-956:
---------------------------------
Hi Guy,
I believe you're thinking of the function of org.jboss.remoting.ConnectionValidator,
rather than LeasePinger.
1. The function of LeasePinger is to send pings to the server to keep a server-side
org.jboss.remoting.Lease alive. If the pings from LeasePinger fail to arrive in time, the
Lease informs server side listeners of a connection problem.
2. The function of ConnectionValidator is to solicit from the server a response to a ping.
If the response does not arrive in time, the ConnectionValidator informs client side
listeners of a connection problem.
So it's ConnectionValidator that suffers from the problem you're describing. And,
it turns out that this problem is already covered by JIRA issues:
* Release 2.2.2.SP8: JBREM-947: ConnectionValidator hangs when server dies
* Release 2.4.0.GA: JBREM-948: CLONE [JBREM-947] - ConnectionValidator hangs when server
dies
If I'm missing something, please let me know. Otherwise, I will close the issue (but
still solve the problem).
Thanks.
Client side does not detect connection drop when LeasePinger is
active, therefore remaining blocked.
----------------------------------------------------------------------------------------------------
Key: JBREM-956
URL:
http://jira.jboss.com/jira/browse/JBREM-956
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: transport
Affects Versions: 2.0.0.GA (Boon), 2.4.0.Beta1 (Pinto), 2.4.0.CR1 (Pinto), 2.2.0.GA
(Bluto), 2.2.0.SP1, 2.2.0.SP2, 2.2.0.SP3, 2.2.0.SP4, 2.2.1.GA, 2.2.2.GA, 2.2.2.SP1,
2.2.2.GA_CP01, 2.2.2.SP2, 2.2.2.GA_CP02, 2.2.2.GA_CP03, 2.2.2.SP4, 2.2.2.SP5, 2.4.0.Beta2
(Pinto)
Environment: JBoss 4.2.1, Windows XP SP2, Redhat Enterprise Linux 3.0
Reporter: Guy Nir
Assigned To: Ron Sigal
Fix For: 2.4.0.GA
When a client and server resides on different machines and server suddenly disconnected
from the network (i.e.: cable disconnected or host is cord-reseted/power down brutely) the
client side does not recognize this situation and remains blocking.
The main reason for this behavior is that TCP does not provide direct indication that a
connection is dropped (unless a probe such as KeepAlive is activated).
The LeasePinger class should resolve this issue, however, the invocation of
sendClientPing() method remains blocking as well.
A different shorter timeout should be placed for sendClientPing() (perhaps
timeout-per-invocation approach ?).
For example, instead of using the following implementation (taken from sendClientPing) :
Map clientsClone = new ConcurrentHashMap(clients);
Map requestClients = new ConcurrentHashMap();
requestClients.put(ClientHolder.CLIENT_HOLDER_KEY, clientsClone);
InvocationRequest ir = new InvocationRequest(invokerSessionID, null,
"$PING$", requestClients, null, null);
invoker.invoke(ir);
It is possible to use:
int clientPingLeaseTimeout = ......;
Map clientsClone = new ConcurrentHashMap(clients);
Map requestClients = new ConcurrentHashMap();
requestClients.put(ClientHolder.CLIENT_HOLDER_KEY, clientsClone);
requestClients.put(ServerInvoker.TIMEOUT, clientPingLeaseTimeout);
InvocationRequest ir = new InvocationRequest(invokerSessionID, null,
"$PING$", requestClients, null, null);
invoker.invoke(ir);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: