[
https://issues.jboss.org/browse/WFLY-4413?page=com.atlassian.jira.plugin....
]
jeremy_lv lv commented on WFLY-4413:
------------------------------------
Hi [~swd847]:
I think you might misunderstand what I want to express here, here's some of my
comments in line:
{quote}
There is nothing that says we need to immediately close the connection after the request
is done. If we did that then browsers would need to create a new connection for every
request, which is very slow. If you really want the connection to close immediately for
some reason just send a connection:close header.
{quote}
I agree with you that we can send a connection:close header to close the connection by
adding the following configurations in the Undertow subsystem and the conection will be
closed normally both the request and response is done:
<filter-ref name="connection-close"/>
<response-header name="connection-close" header-name="Connection"
header-value="close"/>
But to my case, the network connection is broken before response is done because of some
unexpected network problem, the connection leak number will be increased by 1 for each
request and never released. As the time passed by, the connection will continue to
increase until reach its maximum value.
Please take notice of the *step5* in the reproduced steps, I have press the
"Esc" button in five seconds, which means the connection will be interrupted
when accessing the asychronous servlet before the response is done and the leaked
connection won't be released any longer.
Network connection leak in asynchronous servlet
-----------------------------------------------
Key: WFLY-4413
URL:
https://issues.jboss.org/browse/WFLY-4413
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.1.0.Final, 8.2.0.Final
Environment: Linux
Reporter: jeremy_lv lv
Assignee: Stuart Douglas
Priority: Blocker
Labels: undertow
{panel:title=Phenomenon|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
When the connection is suddenly terminated during the period we access the asynchronous
servlet application, the connection will be leaked. However, the connection won't be
leak when we access the synchronous servlet application.
{panel}
*Some of the stacktrace are as follows:*
{panel:title=Stacktrace|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#FFFFCE}
14:34:23,751 ERROR [io.undertow.request] (default task-22) Blocking request fail
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java
at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(As
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) [rt.jar:1
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0
at sun.nio.ch.IOUtil.write(IOUtil.java:51) [rt.jar:1.7.0_25]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) [rt.ja
at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(Htt
at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpRespon
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(Abstr
at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkCha
at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStre
at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputS
at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpSer
... 6 more
{panel}
*Here's the test war code you can used to reproduce this phenomenon:*
{code:title=AsyncDemoServlet.java|borderStyle=solid}
package com.suning.esb.test;
import java.io.IOException;
import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@WebServlet(urlPatterns="/asyncDemoServlet",asyncSupported=true)
public class AsyncDemoServlet extends HttpServlet {
private static final long serialVersionUID = 1L;
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
//Execute the business logic in sub-thread.
AsyncContext ctx = request.startAsync();
new Thread(new Executor(ctx)).start();
}
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}
public class Executor implements Runnable {
private AsyncContext ctx = null;
public Executor(AsyncContext ctx){
this.ctx = ctx;
}
public void run(){
try {
//wait for 5 seconds to simulate the business logic.
Thread.sleep(5000);
ctx.complete();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)