New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-configured customizers are stil applied on a user-defined ServletWebServerFactory #24574
Comments
Thanks for the report. As of Spring Boot 2.3, we are auto-configuring thread-pool related information, see #19475 and the release notes. Assuming that's all you have in your app, you can remove that code and use the Also, exposing a @Bean
WebServerFactoryCustomizer<JettyServletWebServerFactory> jettyThreadPoolCustomizer(QueuedThreadPool threadPool) {
return (factory) -> factory.setThreadPool(threadPool);
} With all that being said, I'd like to keep this issue open to investigate how we could potentially react to the fact a thread pool has already been set (and backoff our customisations). I also think that this section of the doc may need a refresh as I was expecting all the customizers to back off if we create our own factory and they didn't. |
Thanks for the info @snicoll ! Yes we will be switching to the server.jetty.threads-properties. So that solves our problem. I reported it since it's a little bit hard to spot that this happened. The application starts just fine but your custom configuration is no longer present. |
Yup, and thank you again for doing that. A customizer runs after ours by default so the code I've shared in my previous comment is the idiomatic way to customise a server and yet benefit from the rest of the auto-configuration. We've started to chat about this issue and we'll try to improve it so that it is less surprising. |
This bug occurs if you are using Jetty and Spring Boot version 2.4.1.
If you set a custom ThreadPool on your JettyServletWebServerFactory, then that thread pool was used for http requests in 2.2.0. After upgrading to version 2.4.1 that thread pool is no longer being used.
I.e. somewhere in your setup you have this code and you would expect the thread pool to be used.
I've created a sample project that replicates the bug:
https://github.com/plilja/spring-boot-threadpool-bug
You can switch Spring boot version in that project to see that this worked in 2.2.0.
The text was updated successfully, but these errors were encountered: