[jboss-jira] [JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection

[Stuart Douglas (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13110261#comment-13110261 ] 

Stuart Douglas commented on WFLY-4827:
--------------------------------------

I don't know why I did not think about this before but this could be a TCP configuration issue with your system. If the client just drops out entirely and you do not have TCP keepalive it can be a long time before the socket times out (there is nothing that can be done in this case other than time out, as there is no way to tell the difference between the client loosing connectivity vs the client just taking a while to sent).

I think your only real option here is to configure some appropriate timeouts, either the Undertow read timeout, or at a TCP level.




> Network Connection leak on client abort connection
> --------------------------------------------------
>
>                 Key: WFLY-4827
>                 URL: https://issues.jboss.org/browse/WFLY-4827
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow), Web Sockets
>    Affects Versions: 8.2.0.Final
>         Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
>            Reporter: Andrea Bertolini
>            Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored. 
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.  
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call. 
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response. 
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore). 
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze. 
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)