Skip to content

Enable RestClientAutoConfiguration in reactive web applications when virtual threads are enabled #44912

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

Closed
philwebb opened this issue Mar 26, 2025 · 2 comments
Labels
status: superseded An issue that has been superseded by another

Comments

@philwebb
Copy link
Member

Currently RestClientAutoConfiguration uses NotReactiveWebApplicationCondition so that it is only enabled for non-reactive web applications which helps prevent users from accidentally blocking the event loop thread.

This foot-gun protection is less useful when virtual threads are enabled, as we configure WebFlux with an async task executor which allows blocking calls to be made for any controller method that does not return reactive types. Since RestClientAutoConfiguration provides a lot of helpful functionality, we should relax the condition to a NotReactiveWebApplicationOrVirtualThreadsEnabledCondition

@philwebb philwebb added the type: enhancement A general enhancement label Mar 26, 2025
@philwebb philwebb added this to the 3.5.x milestone Mar 26, 2025
@kwondh5217
Copy link
Contributor

Hi @philwebb!
I'd like to contribute to this issue.

Would the following approach make sense to you?

@ConditionalOnThreading(Threading.PLATFORM)
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.REACTIVE)
private static final class ReactiveWebAppWithPlatformThread {
}

@philwebb
Copy link
Member Author

Closing in favor of PR #44952. Thanks @dmitrysulman!

@philwebb philwebb closed this as not planned Won't fix, can't repro, duplicate, stale Apr 15, 2025
@philwebb philwebb added status: superseded An issue that has been superseded by another and removed type: enhancement A general enhancement labels Apr 15, 2025
@philwebb philwebb removed this from the 3.5.x milestone Apr 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
2 participants