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

[Andrea Bertolini (JIRA)]

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

Andrea Bertolini edited comment on WFLY-4827 at 7/1/15 7:05 AM:
----------------------------------------------------------------

Skipping tests I succeed in building jars. I've tested this new version and problem still persist. 

I've used jconsole to check default-task and i've noticed that many tasks are stuck in a wait operation during the read phase from the stream.

Stack trace: 
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
   - locked sun.nio.ch.Util$2 at 77874f09
   - locked java.util.Collections$UnmodifiableSet at 24c4e3e0
   - locked sun.nio.ch.WindowsSelectorImpl at 2d48e7c7
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
org.xnio.nio.NioSocketConduit.awaitReadable(NioSocketConduit.java:345)
org.xnio.conduits.AbstractSourceConduit.awaitReadable(AbstractSourceConduit.java:66)
io.undertow.conduits.ReadDataStreamSourceConduit.awaitReadable(ReadDataStreamSourceConduit.java:101)
org.xnio.conduits.AbstractSourceConduit.awaitReadable(AbstractSourceConduit.java:66)
org.xnio.conduits.ConduitStreamSourceChannel.awaitReadable(ConduitStreamSourceChannel.java:151)
io.undertow.channels.DetachableStreamSourceChannel.awaitReadable(DetachableStreamSourceChannel.java:77)
io.undertow.server.HttpServerExchange$ReadDispatchChannel.awaitReadable(HttpServerExchange.java:1951)
org.xnio.channels.Channels.readBlocking(Channels.java:295)
io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:170)
io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:146)
[... READ REQUESTS FROM APPLICATION ...]

I even tried to update xnio library to new version 3.3.1, no results.


was (Author: aberto88):
Skipping tests I succeed in building jars. Now I'm going to test this new version.

> 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.3.15#6346)