Spring Suggested WebSocket config causes circular bean reference

Affects: Spring Boot > 2.6.0, Spring Framework 5.3.10

Hello everyone,

right before the weekend I updated our microservices to Spring Boot 2.6.0. Some of them using websockets for real-time synchronization with the UI. A while ago we set them up using the suggested configuration as seen in:

https://github.com/spring-projects/spring-framework/blob/main/src/docs/asciidoc/web/websocket.adoc#simple-broker

Now, without any changes to our code, our websocket configuration contains a circular dependency which can be fully removed when removing the TaskScheduler, which of course isn't the solution, but helps to determine the circular dependency. In my opinion the suggested configuration should not contain a circular dependency when it is not recommended to use them.

One should probably update the documentation to fix this issue.

So far I have found two ways to fix this problem. First being a lazy initialization of the TaskScheduler bean:

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    private TaskScheduler messageBrokerTaskScheduler;

        // Note the @Lazy
    @Autowired
    public void setMessageBrokerTaskScheduler(@Lazy TaskScheduler taskScheduler) {
        this.messageBrokerTaskScheduler = taskScheduler;
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {

        registry.enableSimpleBroker("/queue/", "/topic/")
                .setHeartbeatValue(new long[] {10000, 20000})
                .setTaskScheduler(this.messageBrokerTaskScheduler);

        // ...
    }
}

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    public void configureMessageBroker(MessageBrokerRegistry registry, TaskScheduler messageBrokerTaskScheduler) {

        registry.enableSimpleBroker("/queue/", "/topic/")
                .setHeartbeatValue(new long[] {10000, 20000})
                .setTaskScheduler(messageBrokerTaskScheduler);

        // ...
    }
}

Should the documentation be updated or are there any downsides of using the suggested solutions?

Comment From: mdeinum

Does the second one actually work? That method wouldn't be called by anything, so while it might appear to solve it it would/could break things.

What I think is weird is the while circular dependency in the first place, as there is none. As you are using Spring Boot it might be that parts of that configuration kicks in. Finally you might be better of using constructor injection in your @Configuration class instead of a setter.

Comment From: MoritzHorch

What I think is weird is the while circular dependency in the first place, as there is none. As you are using Spring Boot it might be that parts of that configuration kicks in. Finally you might be better of using constructor injection in your @Configuration class instead of a setter.

This is what I was wondering about as well. This is the reason my application(s) fail to start:

┌─────┐
|  org.springframework.web.socket.config.annotation.DelegatingWebSocketMessageBrokerConfiguration
↑     ↓
|  webSocketConfig
└─────┘

So either something important is missing here or I'm not understanding it correctly.

By the way, you are right about the second one. I should definitely forward this to my colleagues suggesting me this solution. Thanks for that.

Comment From: mdeinum

Running it with --debug or debug=true as property will give you a bit more information on why the circular dependency exists, that might be worthwhile information to come up with a (better?) solution.

Comment From: rstoyanchev

The documentation tries to make use of the messageBrokerTaskScheduler bean that comes with @EnableWebSocketMessageBroker but the same config tries to find and apply all WebSocketConfigurer beans. I'll update the documentation to show @Lazy.

Comment From: MoritzHorch

After debugging into the code a little bit deeper there is nothing that proves @rstoyanchev point otherwise. Running in debug additionally did not help much further, it just validates the explanation once again:

Thanks for updating the documentation @rstoyanchev. Even though, as @mdeinum already mentioned, this may not be the best solution. The @Lazy definitely works, but I guess I'm not too familiar with this topic that one should take my solution for granted.

Comment From: MoritzHorch

Oops, did not want to close it.