Hi Team, I'm developing a web application using spring-boot-starter-webflux(2.1.14.RELEASE),spring-boot-starter-tomcat(2.1.14.RELEASE) and tomcat-embed-core(9.0.35). When I using jmeter for performance testing, an exception occurs. --------------------------------------------------- The server side exception stack: java.lang.IllegalStateException: Calling [asyncPostProcess()] is not valid for a request with Async state [ERROR] at org.apache.coyote.AsyncStateMachine.asyncPostProcess(AsyncStateMachine.java:290) at org.apache.coyote.AbstractProcessor.asyncPostProcess(AbstractProcessor.java:192) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:81) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1590) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) --------------------------------------------------- The jmeter side exception stack: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:161) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:82) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:276) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:294) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:257) at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:199) at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:212) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:679) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:481) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:697) at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:455)
Please provide a minimal (ideally a single servlet) test case to reproduce this issue.
Created attachment 37292 [details] minimal test case
Hi Team, Thank you for your prompt reply. I uploaded the minimal test case, this case is receive the request and forward it to the mock server. An error will occur when the keepAlive of Spring WebClient is set to true. --------------------------------------------------- The code is: @Bean public WebClient webclient() { ReactorResourceFactory factory = new ReactorResourceFactory(); factory.setUseGlobalResources(false); factory.setConnectionProvider(ConnectionProvider.fixed("webclient-conn", 128, 1000)); factory.setLoopResources(LoopResources.create("webclient-loop", 8, true)); ClientHttpConnector connector = new ReactorClientHttpConnector(factory, httpClient -> { return httpClient.tcpConfiguration(c -> c.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 2000) .option(ChannelOption.TCP_NODELAY, true).option(ChannelOption.SO_REUSEADDR, true) .option(ChannelOption.SO_KEEPALIVE, true).doOnConnected(conn -> { conn.addHandlerLast(new ReadTimeoutHandler(60000)).addHandlerLast(new WriteTimeoutHandler(3000)); }).wiretap(true)).keepAlive(true); }); return WebClient.builder().baseUrl("http://127.0.0.1:25090").clientConnector(connector).build(); }
Comment on attachment 37292 [details] minimal test case Correct MIME type
A 24 MB WAR is a long way from a minimal test case. If I run from the JAR something starts but there is no sign of an error. Requests to "/" return 404s. Once I adjust the POM to build a WAR file and deploy it to Tomcat it still returns 404s. Further investigation shows that no Servlets and no Filters are registered. A minimal test case should ideally consist of one servlet and possibly a couple of supporting classes. All source code should be provided. The error should be triggered by a request to that servlet. Without a test case that demonstrates the issue it will be assumed that the root cause is failure to (correctly) handle a previous error and the report will be resolved as invalid.
A month has passed and the requested information has not been provided. Without a minimal test case that reproduces the issue, this report will eventually be closed as WONTFIX.
As per earlier comment, I am assuming that the root cause is failure to (correctly) handle a previous error.
*** Bug 65178 has been marked as a duplicate of this bug. ***
Hello. I'm developing using Tomcat and Java. The following logs will be spit out during operation. ---------------------------------------- Error reading request, ignored throwable:java.lang.IllegalStateException: Calling [asyncPostProcess()] is not valid for a request with Async state [ERROR]\n at org.apache.coyote.AsyncStateMachine.asyncPostProcess(AsyncStateMachine.java:290)\n at org.apache.coyote.AbstractProcessor.asyncPostProcess(AbstractProcessor.java:192)\n at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:81)\n at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)\n at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)\n at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)\n at java.util.concurrent.ThreadPoolExecutor.runWorker(null:-1)\n at java.util.concurrent.ThreadPoolExecutor$Worker.run(null:-1)\n at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)\n at java.lang.Thread.run(null:-1) ---------------------------------------- After investigating, it seems to be an error that occurs when the following this line occurs when tomcat runs a thread. https://code.yawk.at/org.apache.tomcat/tomcat-catalina/9.0.26/org/apache/catalina/core/AsyncContextImpl.java#421 However, The same event cannot occur locally. What settings and requests should I make to get this error? Also, is there a way to handle this error? I guess the log output of this error by line 981 below. Therefore, it cannot be handled. https://fossies.org/linux/apache-tomcat/java/org/apache/coyote/AbstractProtocol.java
Which Tomcat version are you using? The duplicate report indicates 9.0.37. The source code reference in the previous comments suggests 9.0.26. Assuming you are using anything other than the latest 9.0.x release (9.0.44 as I type this), please upgrade to that version and retest. There were fixes in this area in 9.0.44 for the case when clients dropped the connection. As per the previous comments on this issue, if you still see this issue with 9.0.44 then a simple as possible test case is required that recreates the issue.
Thank you for reply. I'm using 9.0.37 version. >There were fixes in this area in 9.0.44 for the case when clients dropped the connection. Sure, I try it. If it happens the error after upgrading version, I'll add a comment.
Given there has been no further comment, I am leaning towards the conclusion an upgrade to 9.0.44 addressed the issue.
Hello. After trying your advice, the bug no longer occurs! I change the status of the ticket to 'Resolved'. Thanks.