Skip to content

Documentation unclear on how to replace deprecated AbstractTaskletStepBuilder#throttleLimit #4389

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
vaclavsvejcar opened this issue May 29, 2023 · 4 comments
Labels
for: backport-to-5.0.x Issues that will be back-ported to the 5.0.x line in: documentation type: bug
Milestone

Comments

@vaclavsvejcar
Copy link

Hello,

I have question about the AbstractTaskletStepBuilder#throttleLimit. JavaDoc says that:

since 5.0, scheduled for removal in 6.0. Use a pooled TaskExecutor implementation with a limited capacity of its task queue instead.

But it's IMHO not obvious how this should be replaced and even official documentation still uses this method (https://docs.spring.io/spring-batch/docs/current/reference/html/scalability.html)

This is the snippet of the code we're using right now

        final int numberOfThreads = 32;
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(numberOfThreads);
        executor.setPrestartAllCoreThreads(true);
        executor.afterPropertiesSet();

....
        
        return new StepBuilder("someName", jobRepository)
                .<ProcessDocumentRequest, ProcessDocumentResponse>chunk(chunkSize, transactionManager)
                .reader(synchronizedItemStreamReader())
                .processor(itemProcessor())
                .writer(documentWriter())
                .taskExecutor(delegatingSecurityContextAsyncTaskExecutor(executor))
                .throttleLimit(numberOfThreads)
                .build();

But it seems when we remove the .throttleLimit it only runs in 4 threads, which seems to be the default value defined in AbstractTaskletStepBuilder by

private int throttleLimit = TaskExecutorRepeatTemplate.DEFAULT_THROTTLE_LIMIT;

Can you please clarify how to set up the task executor so it works in the same way as when using the throttleLimit method?

@vaclavsvejcar vaclavsvejcar added status: waiting-for-triage Issues that we did not analyse yet type: bug labels May 29, 2023
@fmbenhassine
Copy link
Contributor

Thank you for opening this issue. I must admit this is confusing, that's why we are planning to review the concurrency model completely (see #3950).

The issue is that even if one provides a pooled task executor as stated by the javadoc, the TaskExecutorRepeatTemplate will still be used and will be capped at that default throttle limit of 4, and there is no way to override that default without calling the, now deprecated, throttleLimit method..

The correct way to replace that deprecation is actually to go one level up (ie above the TaskExecutor), meaning by using a custom RepeatOperations through AbstractTaskletStepBuilder#stepOperations. This way, TaskExecutorRepeatTemplate won't be used and that method won't need to be called. We will update the javadocs and reference docs accordingly.

@fmbenhassine fmbenhassine added in: documentation and removed status: waiting-for-triage Issues that we did not analyse yet labels Jun 14, 2023
@glyiu98
Copy link

glyiu98 commented Aug 29, 2023

Hey @fmbenhassine, I was trying to do the suggested approach but it seems that the TaskExecutorRepeatTemplate.setThrottleLimit is also deprecated.

Is there any other way to do it?

Thanks!

@fmbenhassine
Copy link
Contributor

@glyiu98 The suggested replacement is to provide a custom RepeatOperations through AbstractTaskletStepBuilder#stepOperations, as mentioned in my previous comment. This way, you don't have to use the TaskExecutorRepeatTemplate at all or call its deprecated setThrottleLimit. We will fix the docs accordingly.

@RT-1904129
Copy link

Hi @fmbenhassine
Can you provide sample hints or example to help me to resolve this issue ?????

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: backport-to-5.0.x Issues that will be back-ported to the 5.0.x line in: documentation type: bug
Projects
None yet
Development

No branches or pull requests

4 participants