Skip to content

Multi-threaded Step job hangs if @StepScope bean cannot be created #3948

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

Open
farnetto opened this issue Jun 21, 2021 · 3 comments
Open

Multi-threaded Step job hangs if @StepScope bean cannot be created #3948

farnetto opened this issue Jun 21, 2021 · 3 comments
Labels
has: minimal-example Bug reports that provide a minimal complete reproducible example in: infrastructure type: bug

Comments

@farnetto
Copy link
Contributor

farnetto commented Jun 21, 2021

If in a multi-threaded step a @StepScope bean cannot be created then the batch just hangs waiting in TaskExecutorRepeatTemplate#waitForResults L172.

In my batch I want to pass in the pool size as a job parameter to the TaskExecutor used in the step. If this parameter is missing or cannot be converted into an int, then an exception is added to the deferred list but the TaskExecutorRepeatTemplate thinks a result is still coming from the ResultQueueResultHolder.

Here is my task executor:

@Bean
@StepScope
public TaskExecutor taskExecutor(@Value("#{jobParameters['poolSize']}") int poolSize) {
	ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
	executor.setCorePoolSize(poolSize);
	executor.setMaxPoolSize(poolSize);
	return executor;
}

Here's a pull request demonstrating the problem:

Apress/def-guide-spring-batch#13

@farnetto farnetto added status: waiting-for-triage Issues that we did not analyse yet type: bug labels Jun 21, 2021
@farnetto farnetto changed the title Parallel Step job hangs if @StepScope bean cannot be created Multi-threaded Step job hangs if @StepScope bean cannot be created Jun 22, 2021
@fmbenhassine
Copy link
Contributor

Thank you for reporting this issue. I do confirm that the TaskExecutorRepeatTemplate hangs in this case (I was able to reproduce the issue in this repo). This kind of exceptions should fail fast and not added to the deferred exceptions list.

That said, I see no added value in making the TaskExecutor step-scoped and I believe the poolSize should not be passed as a job parameter in the first place. Job parameters are designed to be used for "business" runtime parameters (like an input file name, database table, partition meta-data, etc) and not technical configuration parameters like thread poolSize, database connection poolSize, database Url, etc.

@fmbenhassine fmbenhassine added in: infrastructure status: waiting-for-triage Issues that we did not analyse yet and removed status: waiting-for-triage Issues that we did not analyse yet labels Jun 25, 2021
@farnetto
Copy link
Contributor Author

We do see added value in making the TaskExecutor step-scoped and passing in the poolSize as a job parameter. We want to be able to change the poolSize easily in production without redeploying the code or the overall job configuration.

@fmbenhassine
Copy link
Contributor

We want to be able to change the poolSize easily in production without redeploying the code or the overall job configuration.

You can do that with a system property (or a similar mechanism provided by Spring Framework or Spring Boot), something like:

-- $>java -jar myjob.jar poolSize=3
++ $>java -jar myjob.jar -DpoolSize=3
@Bean
-- @StepScope
-- public TaskExecutor taskExecutor(@Value("#{jobParameters['poolSize']}") int poolSize) {
++ public TaskExecutor taskExecutor(@Value("#{systemProperties['poolSize']}") int poolSize) {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(poolSize);
    executor.setMaxPoolSize(poolSize);
    return executor;
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: minimal-example Bug reports that provide a minimal complete reproducible example in: infrastructure type: bug
Projects
None yet
Development

No branches or pull requests

2 participants