[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-956) Client side does not detect connection drop when LeasePinger is active, therefore remaining blocked.

[Guy Nir (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBREM-956?page=comments#action_12407240 ] 
            
Guy Nir commented on JBREM-956:
-------------------------------

Hello Ron.

We're using JBoss 4.2.1 default remoting implementation, which is 2.2.1.GA; this version has a constant timeout (set to 1000ms, without validatorPingTimeout); all other parameters mentioned on the URI are just there to reduce the time it takes to identify a faulty connection.

When we upgrade to version 2.2.2 or above, be sure we would use it.

Ron, keep up the good work. We're counting on JBoss to be an enterprise-grade solution.

Best regards,
Guy.


> 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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira