[jboss-jira] [JBoss JIRA] (WFLY-3652) Network connection leak
[
https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin....
]
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)