Tomcat version: 7.0.92
I am heavily using asynchronous API in my application, which is running on Tomcat 7. One of the requirements that I have -- permit all requests that are currently in flight to complete their work before termination.
I have the following properties set for each of my connectors in server.xml
: asyncTimeout="40000" executorTerminationTimeoutMillis="60000"
Also, unloadDelay
is set to 60 seconds in context.xml
.
I have thrown a 10 seconds sleep into one of my services and I place a curl request against my server, then immediately I request a shutdown of a tomcat service.
curl sits there for about 10 seconds and then it returns 502
from tomcat.
Additionally, in catalina.out
, I see the following stack trace:
INFO: Waiting for 1 instance(s) to be deallocated for Servlet [jersey-servlet]
Dec 05, 2018 7:13:37 PM org.apache.catalina.connector.CoyoteAdapter checkRecycled
INFO: Encountered a non-recycled request and recycled it forcedly.
org.apache.catalina.connector.CoyoteAdapter$RecycleRequiredException
at org.apache.catalina.connector.CoyoteAdapter.checkRecycled(CoyoteAdapter.java:634)
at org.apache.coyote.http11.AbstractHttp11Processor.recycle(AbstractHttp11Processor.java:1909)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.release(Http11NioProtocol.java:220)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:720)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1775)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1734)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Encountered a non-recycled request and recycled it forcedly.
I believe it indicates that something is not working as expected. Seems like HTTP connectors are being shut down prematurely.
Just "for completeness' sake:
according to this Tomcat bug submitted by the author of the question - https://bz.apache.org/bugzilla/show_bug.cgi?id=63003
the problem described was caused by the Tomcat not respecting unloadDelay
context setting, and had been already fixed by now.