Skip to content
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

Doc: ThreadPoolTaskExecutor's defaults vs setting queueCapacity for common pool scenarios [SPR-16944] #21483

Closed
spring-issuemaster opened this issue Jun 15, 2018 · 1 comment

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jun 15, 2018

Constantino Cronemberger opened SPR-16944 and commented

According to ThreadPoolExecutor Javadoc:

"If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full."

In the class ThreadPoolTaskExecutor the default values are: 1 for the corePoolSize and Integer.MAX_VALUE for maxPoolSize and queueCapacity.

This means that a second thread will be created only when we have MAX_VALUE elements in the queue. This is is not reasonable.

I think queueCapacity should not have a default value.


Issue Links:

  • #21484 Doc: AsyncConfigurer causes dependencies to be created early

Backported to: 4.3.19

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jun 17, 2018

Juergen Hoeller commented

Those defaults essentially mimic Executors.newFixedThreadPool(1) / Executors.newSingleThreadExecutor(), sharing a single pooled thread for all tasks. The unbounded maxPoolSize may appear odd here (since it is behaviorally equivalent to a maximum of 1); that setting is primarily there in case of a custom queueCapacity, providing scaling by default at that point (without setting a custom maxPoolSize at the same time).

Making the default queueCapacity 0 and therefore not allowing for any queued tasks would mimic Executors.newCachedThreadPool(), with immediate scaling of threads in the pool to a potentially very high number. While this is not unreasonable in many scenarios, the fixed single thread seems to be safer default. As outlined above, enabling this mode of operation just requires setting queueCapacity to 0, without touching the maxPoolSize setting.

I'll therefore turn this into a documentation task, making those typical scenarios clearer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.