Websocket calls are not being matched by any @MessageMapping in Spring

Hello,

I don’t know if it’s a good practice, but I’ve imported all the classes of optaweb-backend inside my project, built with jhipster. And now I’d like to test if everything works by using the optaweb-client.

Even if my backend code was configured exactly the same as optaweb-backend, I had some problems with incoming Websocket messages. One of them was due to CORS, not accepting the “*” wildcard, fixed by specifying the client hostname “localhost:3000”. Then the client was able to send the handshake correctly.

The problem I’m facing now is that the optaweb-client application is sending the subscription message, but apparently there’s no match in the Spring Controller. This is from the logs:

2020-05-27 21:47:16.090 DEBUG 2761 --- [boundChannel-19] .WebSocketAnnotationMethodMessageHandler : Searching methods to handle SUBSCRIBE /app/topic/route id=sub-1590608836085-631 session=fyprt1oy, lookupDestination='/topic/route'
2020-05-27 21:47:16.090 DEBUG 2761 --- [boundChannel-19] .WebSocketAnnotationMethodMessageHandler : No matching message handler methods.

I’m opening this issue because I see that there are many comments near Websocket setup code, both in optaweb backend and frontend modules. That made me think of a “work in progress” situation. So I tought that it was a good idea to ask the author 😃

I’m referring to this section in particular:

org.optaweb.vehiclerouting.plugin.websocket.WebSocketConfig

@Configuration
@EnableWebSocketMessageBroker
class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        // STOMP messages whose destination header begins with /app are routed to @MessageMapping methods
        // in @Controller classes.
        // Not sure if "/topic" should be an application prefix but I couldn't get @SubscribeMapping("/route") working
        // without this.
        registry.setApplicationDestinationPrefixes("/app", "/topic");
        // Use the built-in message broker for subscriptions and broadcasting,
        // and route messages whose destination header begins with /topic to the broker.
        registry.enableSimpleBroker("/topic");
    }

   // ....
}

Client - Server messaging

By setting websocket logging to debug, I can see the configured message endpoints printed at boot time:

	it.****.****.web.websocket.WebsocketController:
	{[MESSAGE],[/clear]}: clear()
	{[MESSAGE],[/location/{id}/delete]}: removeLocation(long)
	{[MESSAGE],[/vehicle/{id}/delete]}: removeVehicle(long)
	{[MESSAGE],[/location]}: addLocation(PortableLocation)
	{[MESSAGE],[/vehicle]}: addVehicle()
	{[MESSAGE],[/vehicle/{id}/capacity]}: changeCapacity(long,int)
	{[MESSAGE],[/vehicle/deleteAny]}: removeAnyVehicle()
	{[SUBSCRIBE],[/serverInfo]}: subscribeToServerInfoTopic()
	{[SUBSCRIBE],[/route]}: subscribeToRouteTopic()
	{[MESSAGE],[/demo/{name}]}: demo(String)

The client application is sending this message (without escape codes):

[" SUBSCRIBE
   id: sub-1590608836084-262
   destination: /app/topic/serverInfo "]

Please, check the request headers:

Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: ###########
Sec-WebSocket-Version: 13
Upgrade: websocket

It seems that the Sec-WebSocket-Protocol key is missing, by reading this paragraph in the official Spring docs.

As you can see from my logs, the controller endpoints are not prefixed by “/topic” or “/app” in the controller, so why it works in the original project, and not in mine?!

Project dependencies

To give you the last informations, some dependencies in my project:

Spring

• spring-boot: 2.2.7.RELEASE
• spring-core: 5.2.6.RELEASE
• spring-security-core: 5.2.4.RELEASE
• spring-security-messaging: 5.2.4.RELEASE
• spring-boot-starter-websocket: 2.2.7.RELEASE
• spring-websocket: 5.2.6.RELEASE
• spring-messaging: 5.2.6.RELEASE

Optaplanner

• optaplanner-spring-boot-starter: 7.37.0.Final:compile
• optaplanner-spring-boot-autoconfigure: 7.37.0.Final
• optaplanner-core: 7.37.0.Final

Conclusion

If the post is too long, I apologize for that, and form my english too! I’d like to specify that i’m not seeking for help (although any advices are welcome!), my intent is just to share my experience, in order to reply to the comments found in the code. It’s important for me to understand if the problem I’m facing can be related to my dependencies versions, a fault with the project configuration, or whatever.

Just a personal note… I’m happy to have found this project, I always wanted to work with something related to finding the best route. It’s just now that I’ve found informations about the VR Problem, I wasn’t aware of its notoriety. However I wanted to send a thank you to the project creators, I hope with time to learn to use this library well, and why not, also make a contribution in the future if there will be the occasion.

Thanks for reading! 😉 Federico

[yurloc]

Closing. Without a reproducer there is nothing to fix upstream.

But thank you for the detailed report! It maybe useful for someone in the future.

[funder7]

Well, I think that the problem can be related to spring-boot version. I’m not completely sure about it, but it can be possible. I just wanted to point out what happened to me, in case the spring version of optaweb-vehicle-routing will be upgraded in the future, making the same problem come out.

Even if my project was generated with Jhipster, I’ve seen only one difference: the configuration class WebConfig implements ServletContextInitializer, WebServerFactoryCustomizer<WebServerFactory> instead of WebMvcConfigurer.
So again i think more about something changed in the latest versions.

There’s another quite strange thing that happened: I struggled for days after importing your code inside my spring application, trying to find out why the solver was dying after just a couple of operations. It made me nearly go insane! Even with debugging set to “TRACE”, I couldn’t find what was causing the problem. Finally, while reading Optaplanner’s documentation, and just by luck I’ve found a little note saying that drools doesn’t play well with spring-boot-devtools module. Once disabled, the solver started and continued to work without any problem. I wouldn’t believe my eyes when I saw it calculating the score!

It’s quite strange, I’ve checked optaweb-vehicle-routing pom, and spring-boot-devtools is there, but it’s not causing problems.

So just be cautious when upgrading dependencies, these two problems can around the corner. Just remember my words, maybe they will save you from a big headache 😄