[
https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin....
]
Jan Vanhercke updated WFLY-3652:
--------------------------------
Description:
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.
was:
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 the JVM but are in fact half closed by the network stack.
Not all connections appear leak, but over time, depending on the load, the server instance
fills up.
Network connection leak
-----------------------
Key: WFLY-3652
URL:
https://issues.jboss.org/browse/WFLY-3652
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
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
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.2.6#6264)