[
https://issues.jboss.org/browse/WFLY-3652?page=com.atlassian.jira.plugin....
]
Stuart Douglas commented on WFLY-3652:
--------------------------------------
Which side of the network stack is half closed in this case? I assume the server has
closed its side, and the client is keeping it open?
By default Undertow does not close the request stream when the response stream is closed,
as it is perfectly valid to continue to process request data after the response has
already been written (although probably not that common).
I could change the behaviour to force close (i.e. RST) the request when the response is
done, but this has some negative consequences. Force closing when async servlets are in
use could potentially be a solution, although really the application should just be
calling AsyncContext.complete() when the request is done.
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)