Does Spring @SubscribeMapping really subscribe the client to some topic?

by

By default the return value from an @SubscribeMapping method is sent
as a message directly back to the connected client and does not pass
through the broker.

(emphasis mine)

Here the Spring Framework documentation is describing what happens with the response message, not the incoming SUBSCRIBE message.

So to answer your questions:

  • yes, the client is subscribed to the topic
  • yes, the clients subscribed to that topic will receive a message if you use that topic to send it
  • the message broker is in charge of managing subscriptions

More on subscription management

With the SimpleMessageBroker, the message broker implementation lives in your application instance. Subscription registrations are managed by the DefaultSubscriptionRegistry.
When receiving messages, the SimpleBrokerMessageHandler handles SUBSCRIPTION messages and register subscriptions (see implementation here).

With a “real” message broker like RabbitMQ, you’ve configured a Stomp broker relay that forwards messages to the broker. In that case, the SUBSCRIBE messages are forwarded to the broker, in charge of managing subscriptions (see implementation here).

Update – more on STOMP message flow

If you take a look at the reference documentation on STOMP message flow, you’ll see that:

  • Subscriptions to “/topic/greeting” pass through the “clientInboundChannel” and are forwarded to the broker
  • Greetings sent to “/app/greeting” pass through the “clientInboundChannel” and are forwarded to the GreetingController. The controller adds the current time, and the return value is passed through the “brokerChannel” as a message to “/topic/greeting” (destination is selected based on a convention but can be overridden via @SendTo).

So here, /topic/hello is a broker destination; messages sent there are directly forwarded to the broker. While /app/hello is an application destination, and is supposed to produce a message to be sent to /topic/hello, unless @SendTo says otherwise.

Now your updated question is somehow a different one, and without a more precise use case it’s difficult to say which pattern is the best to solve this. Here are a few:

  • you want the client to be aware whenever something happens, asynchronously: SUBSCRIBE to a particular topic /topic/hello
  • you want to broadcast a message: send a message to a particular topic /topic/hello
  • you want to get immediate feedback for something, for example to initialize the state of your application: SUBSCRIBE to an application destination /app/hello with a Controller responding with a message right away
  • you want to send one or more messages to any application destination /app/hello: use a combination of @MessageMapping, @SendTo or a messaging template.

If you want a good example, then check out this chat application demonstrating a log of Spring websocket features with a real world use case.

Leave a Comment