-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Using a forkjoin thread in Webflux will cause classes and static resources to fail to load #34742
Comments
I am pretty sure that this is a duplicate of #19427. You need to configure the If this doesn't help and you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue. Unfortunately, it's very hard to understand what's happening from screenshots of your IDE. |
When using Completablefuture.runaync, do I need to set the class loader as follows? Thread.currentThread().setContextClassLoader(WebPageController.class.getClassLoader()); but this is obviously caused by mixing webflux threads with jdk's forkjoin threads. Should spring-webflux separate the reactive threads in webflux into a separate thread pool? |
Unfortunately, I can't help with any guidance on exactly what you need to do as I haven't seen your code. |
The threads in webflux use the threads in the forkjoin thread pool, if the business code on the use of fokrjoin threads will have an impact, I would like to understand why not separate the two? |
reactor/reactor-netty#2582 |
jdk17.0.4 spring-webflux 2.7.9 alpine-linux 3.12.9
1.Start the spring container, which will set the launchedurlclassloader as the default classloader in the thread
2.When loading to a bean with an asynchronous task and that task uses complatablefuture.runaync, the classloader in the thread will be changed to ClassLoader.getSystemClassLoader()
3.The third step is to start the reactive thread, which also uses the same thread to setContextClassLoader, if everything goes according to such rules without any problems.
Let's assume that steps 1 2 3 are multiplexing the same thread, or if step 2 is a timed task, the classloader in the reactive thread will be changed to ClassLoader.getSystemClassLoader(), which will try to invalidate the class loading or static resource loading in this business thread
The text was updated successfully, but these errors were encountered: