Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-15962

TaskExecutorRegistration.getTaskExecutor() overrides executor properties of a provided ThreadPoolTaskExecutor

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 4.2.9
    • Fix Version/s: 4.3.12, 5.0 GA
    • Component/s: Messaging:WebSocket
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                juergen.hoeller Juergen Hoeller
                Reporter:
                bjstocco Brian Stocco
                Last updater:
                Spring Issuemaster
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  47 weeks, 4 days ago