how to await subscriptions established?

Question

I have the following js code:

stompClient.subscribe('/topic/clients', function (calResult) {
    updateClientsTable(JSON.parse(calResult.body));
});
$.get("/clients", null);

and following server code(last line invokes it):

 @GetMapping(value = {"/clients"})
 @ResponseBody
 public void loadClients() {
      brokerMessagingTemplate.convertAndSend("/topic/clients", clientService.getClientList());
 }

Sometime front-end misses result of $.get("/clients", null);

As I understand problem: at the moment of result getting on front end, subscriptions is not happens.

if to put $.get("/clients", null); below in the code - all works fine.

Can you explain how to await subscriptions established?

Answer 1

As @light_303 already mentioned, mixing HTTP requests with notification mechanism isn't good. You can register moment, when client connects (GET request on /clients), but you can't register when he disconnects.

You should think in one of the next ways. When user subscribes to /topic/clients:

1. You individually send him response with all client list and then push updates only.
2. You individually send him current server time or some kind of ID and then push updates only. User uses given time/ID in GET request to /clients and receives full client list on that moment. This option can be good in situation, when you have incremental updates (i. e. adding new elements to list) and otherwise not so good.

Check this question: Sending message to specific user on Spring Websocket.

This is actually ridiculous, how Spring can complicate things. I recommend you to look on another frameworks for real-time web communication, such as Vert.x or Netty and on Go programming language. Use WebSockets or SockJS instead of STOMP. All that technologies can give you more flexible and performant solution in obvious way. Also, check Centrifugo project, maybe it's relevant to your task.

Answer 2

I think it would make more sense to not mix REST requests with this messaging pattern.

Have you considered sending the "updateClients" command through SockJS into an "/apps/updateClients" channel which replies to the "/topic/clients" channel?