-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
ThreadPoolaskExecutor blocks endless #4316
Comments
Thank you for opening this issue. I will plan the work on this for 5.0.2. As mentioned in SO, I think the issue is with the default throttle limit value of the BTW, we acknowledge this is confusing, that's why that throttle limit is deprecated for removal (#2218) and the concurrency model will be reviewed in #3950. |
@fmbenhassine thanks for update |
Hi @MelleD , When I try your sample with the import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
@SpringBootApplication
public class SpringBatchExampleApplication {
public static void main(String[] args) {
ConfigurableApplicationContext applicationContext = SpringApplication.run(SpringBatchExampleApplication.class, args);
ThreadPoolTaskExecutor taskExecutor = applicationContext.getBean(ThreadPoolTaskExecutor.class);
taskExecutor.shutdown();
}
} And here is the full log:
I attach the zip of the minimal complete example (I just removed the web bits and used your
So as I mentioned in SO, the Looking forward to your feedback. |
Thank you for your detailed answer, but I'm not sure if I understood it correctly. The ThreadPoolExecutor is normally only terminated when the server is stopped. That's why I don't quite understand what the solution is, because normally the ThreadPoolExecutor lives during the whole lifecycle. |
Yes, in a webapp that runs 24/7 there is no need to shut it down, it will be shutdown automatically when the server stops. The sample you shared initially is a webapp, and after all jobs submitted through the web controller are finished, the task executor will wait for other jobs to be submitted as long as the webapp is running. It does not block endless, it is there waiting for next jobs to run. To me there is no problem and this is no issue. The only doubt you raised in SO is about the size of the core pool size:
That's what I tried to clarify through the sample: things works as expected even with a core pool size of 4. The other point about the thread pool lifecycle is a no issue. Hopefully this clarifies things further. |
I am closing this ticket as I believe it is a no issue as explained previously, but you can add a comment if you need more help on the case. |
Based on the post here, which problem I can still reproduce by clicking in the browser several times.
But unfortunately I still don't quite understand the reason for the endless blocking.
On the tip of @fmbenhassine I also made the JobExecutor asynchron not only the steps
But same result on some time the Threads are blocked and I see no ouput.
The third try was without REST Api, just on Application startup.
But also blocked.
Maybe someone has a good hint for me and generally a few good tips for ThreadPoolTaskExecutor settings
Minimal Complete Reproducible example
For Problem 1 without asynchron job executor.
(https://github.com/MelleD/spring-batch-example)
The text was updated successfully, but these errors were encountered: