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

TaskExecutorRegistration.getTaskExecutor() overrides executor properties of a provided ThreadPoolTaskExecutor [SPR-15962] #20514

spring-issuemaster opened this issue Sep 14, 2017 · 1 comment


None yet
2 participants
Copy link

commented Sep 14, 2017

Brian Stocco opened SPR-15962 and commented

When configuring the threadpool for the websocket clientOutboundChannel for example I will override public void configureClientOutboundChannel(ChannelRegistration registration). On the ChannelRegistration I can call taskExecutor(taskExecutor) and provide a ThreadPoolTaskExecutor which is set in the the ChannelRegistration's TaskExecutorRegistration.

However, when the getTaskExecutor() method is called on the TaskExecutorRegistration my ThreadPoolTaskExecutor is used, but the default settings for the TaskExecutorRegistration then immediately override whatever was set on the ThreadPoolTaskExecutor I provided.

This doesn't seem like the intended logic. I would expect to either provide the settings to the TaskExecutorRegistration and have it create a ThreadPoolTaskExecutor with those settings for me, or provide my own ThreadPoolTaskExecutor object, but I would not expect to have some settings overridden on the provided ThreadPoolTaskExecutor.

I encountered this in 4.2.9, but the latest source code in Github still seems to have this issue.

Affects: 4.2.9

Issue Links:

  • #20517 JmsMessagingTemplate is not correctly configured
  • #20527 ChannelRegistration.setInterceptors is misnamed

Referenced from: commits d11bd64, ac9cfef

Backported to: 4.3.12


This comment has been minimized.

Copy link
Collaborator Author

commented Sep 19, 2017

Juergen Hoeller commented

Indeed, these defaults are only meant to be applied to a default executor. I've revised the overall implementation to cleanly separate between a default and a user-provided executor, and to only apply user-specified settings (from actual TaskExecutorRegistration calls) there.

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