[jboss-jira] [JBoss JIRA] (WFLY-3652) Network connection leak

[Seth Miller (JIRA)]

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

Seth Miller commented on WFLY-3652:
-----------------------------------

I was able to mitigate the file-handle leak with ASYNC, but not the memory leak.  The file-handle leak was caused by the use of ServletOutputStream.print() as mentioned here: http://bugs.cometd.org/browse/COMETD-552 - this was an issue with Undertow 1.1.0beta7.  Updating to CometD 3.0.1 or 2.9.2 will fix the file-handle portion of the leak.


> Network connection leak
> -----------------------
>
>                 Key: WFLY-3652
>                 URL: https://issues.jboss.org/browse/WFLY-3652
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.1.0.Final
>         Environment: Linux 2.6.38-16-server
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
>            Reporter: Jan Vanhercke
>            Assignee: Stuart Douglas
>             Fix For: 9.0.0.Alpha1
>
>
> When using Asynchronous servlets and AsyncListeners for long polling we observe a connection leak in the undertow subsystem.
> Heap dumps show a large number of org.xnio.io.NioSocketConduit, io.undertow.server.protocol.http.HttpServerConnection and related objects.
> However, since the effective number of connections is far less, nearly all AsyncContext instances we find are in a complete state and lsof output returns a large number of sockets with 'can't identify protocol' entries indicating that sockets are kept open by the JVM but are in fact half closed by the network stack.
> Not all connections appear to be leaking, but over time, depending on the load, the server instance fills up. 



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)