Servlet destroy() timeout

20 views
Skip to first unread message

Brad Wood

unread,
Apr 8, 2025, 1:18:31 PMApr 8
to Undertow Dev
The Javadocs for the Servlet class's destroy() method say this:

>  This method is only called once all threads within the servlet's service method have exited or after a timeout period has passed. 

Glancing through the Undertow source code, I'm having a hard time figuring out if Undertow is following this.  Is there a mechanism in place to wait for existing requests to finish before shutdown?  Also, does Undertow's servlet manager implement a shutdown timeout, and if so, how and where is it configured?

And finally, does the GracefulShutdownHandler serve a purpose in a Servlet deployment of Undertow or is it unnecessary?

Thanks!

~Brad

Brad Wood

unread,
Apr 16, 2025, 12:51:06 AMApr 16
to Undertow Dev
Any input here?

Flavia Rainone

unread,
Apr 24, 2025, 6:36:54 PMApr 24
to Undertow Dev
Hi Brad,

Yes, Undertow is following the spec and it invokes destroy(). ManagedServlet is the class used internally to represent a servlet and ManagedServlet.stop() is the method responsible for invoking the servlet destroy method.

GracefulShutdownHandler serves no purpose regarding deployment apart from the fact that you probably will want to invoke DeploymentManager.stop() when the GracefulShutdownHandler notifies you all requests have been handled. So, you can use the handler to learn when it is safe to invoke the stop method. By doing that, you will make sure that destroy is invoked in your servlets in a graceful shutdown way.

Best regards,
Flavia

Brad Wood

unread,
Apr 24, 2025, 6:53:18 PMApr 24
to Flavia Rainone, Undertow Dev
> Yes, Undertow is following the spec and it invokes destroy().

To be clear, I didn't ask whether or not Undertow simply calls the .destroy() method.  I asked if Undertow follows the servlet spec in that the destroy method will not be called until "all threads within the servlet's service method have exited or after a timeout period has passed."

The servlet spec seems to imply that the servlet container is required to provide a graceful shutdown automatically, which seems that it would be unneccessary to use the graceful shutdown handler if the container is already enforcing this for me (per the spec).  This, of course, assuming I'm using Undertow as a servlet and not just a stand-alone Java server.  You seem to be saying I would still need to use the graceful shutdown handler even when using undertow to manage the servlet deployment, which implies Undertow is not following the spec.  Please clarify.  

Thanks!

~Brad

Developer Advocate
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 



--
You received this message because you are subscribed to the Google Groups "Undertow Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to undertow-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/undertow-dev/f7bddfe4-8a62-49f4-96ed-e2ca1e0b783an%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Flavia Rainone

unread,
Apr 24, 2025, 7:18:09 PMApr 24
to Undertow Dev
Oh, I see now what you mean.

So, the WildFly server is our Jakarta Servlet certified implementation. Undertow contains the pieces used by WildFly, but in order to have the spec fully followed you will need to invoke the GracefulShutdownHandler.

Also, it is interesting to point out that, in the other thread, I said it doesn't make difference which one you do first: Undertow.stop and undeploy. But, in reality, it does. Only when invoking Undertow.stop() you will have the threads fully stopped. When stopping the server in a spec compliant way, probably the order you are looking at is: 1. stop() the deployment; 2. stop() the server;  and  3. undeploy. Notice that Undertow.stop() will block until the threads are shutdown if UndertowOptions.SHUTDOWN_TIMEOUT is undefined, guaranteeing you they are gone when Undertow.stop() returns.

Brad Wood

unread,
Apr 24, 2025, 7:27:57 PMApr 24
to Flavia Rainone, Undertow Dev
Interesting.  So:
  1. each/deployment.stop()
  2. server.stop()  // blocks
  3. each/deployment.undeploy()
So where then does the additional logic of the shutdown handler fit in the above steps?  Am I waiting for the graceful shutdown handler to give the green flag before I start any of the steps above?

At the point in time the server needs to shut down, would it be like so?
  1. each/shutdownHandler.shutdown();
  2. each/shutdownHandler.awaitShutdown( timeout );
  3. each/deployment.stop()
  4. server.stop()  // blocks
  5. each/deployment.undeploy()

Thanks!

~Brad

Developer Advocate
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 


Reply all
Reply to author
Forward
0 new messages