Stomp oltre websocket utilizzando primavera e sockJS messaggio perso

Question

Sul lato client JavaScript Ho

stomp.subscribe("/topic/path", function (message) { 
     console.info("message received"); 
    }); 

E sul lato server

public class Controller { 
    private final MessageSendingOperations<String> messagingTemplate; 
    ＠Autowired 
    public Controller(MessageSendingOperations<String> messagingTemplate) { 
     this.messagingTemplate = messagingTemplate; 
    } 
    @SubscribeMapping("/topic/path") 
    public void subscribe() { 
    LOGGER.info("before send"); 
    messagingTemplate.convertAndSend(/topic/path, "msg"); 
    } 
} 

Da questa configurazione, sono di tanto in tanto (circa una volta ogni 30 pagina si rinnova) sperimentando la caduta del messaggio, il che significa che non riesco a vedere né il messaggio "messaggio ricevuto" sul lato client né il traffico websocket dallo strumento di debug di Chrome.

"before send" è sempre registrato sul lato server.

Sembra che MessageSendingOperations non sia pronto quando lo chiamo nel metodo subscribe(). (se inserisco Thread.sleep (50), prima di chiamare messagingTemplate.convertAndSend il problema scomparirebbe (o molto meno probabilmente sarà riprodotto))

Mi chiedo se qualcuno abbia mai sperimentato lo stesso prima e se c'è un evento che può dimmi che MessageSendingOperations è pronto o no.

Answer 1

Il problema che state affrontando è nella natura di clientInboundChannel che è ExecutorSubscribableChannel per impostazione predefinita.

Ha 3 subscribers:

0 = {SimpleBrokerMessageHandler@5276} "SimpleBroker[DefaultSubscriptionRegistry[cache[0 destination(s)], registry[0 sessions]]]" 
1 = {UserDestinationMessageHandler@5277} "UserDestinationMessageHandler[DefaultUserDestinationResolver[prefix=/user/]]" 
2 = {SimpAnnotationMethodMessageHandler@5278} "SimpAnnotationMethodMessageHandler[prefixes=[/app/]]" 

che sono richiamato all'interno taskExecutor, quindi in modo asincrono.

La prima qui (SimpleBrokerMessageHandler (o StompBrokerRelayMessageHandler) se si utilizza broker-relay) è responsabile per registrare subscription per il topic.

L'operazione messagingTemplate.convertAndSend(/topic/path, "msg") può essere eseguita prima della registrazione della sottoscrizione per quella sessione WebSocket, poiché vengono eseguite nei thread separati. Quindi il gestore Broker non sa che tu invii il messaggio alla sessione.

Il @SubscribeMapping può essere configurato sul metodo con return, in cui il risultato di questo metodo verrà inviato come risposta a tale funzione subscription sul client.

HTH

Answer 2

Un po 'tardi, ma ho pensato di aggiungere la mia soluzione. Stavo avendo lo stesso problema con la sottoscrizione non essere registrato prima che stavo inviando i dati attraverso il modello di messaggistica. Questo problema si è verificato raramente e imprevedibile a causa della corsa con lo DefaultSubscriptionRegistry.

Purtroppo, non ho potuto utilizzare il metodo di ritorno dello @SubscriptionMapping perché stavamo usando un mappatore di oggetti personalizzato modificato dinamicamente in base al tipo di utente (essenzialmente il filtro degli attributi).

Ho cercato attraverso il codice Spring e trovato SubscriptionMethodReturnValueHandler era responsabile dell'invio del valore restituito dei mapping di sottoscrizione e disponeva di un diverso messagingTemplate rispetto al del controller asincrono automaticamente !!

Quindi la soluzione stava automatizzando MessageChannel clientOutboundChannel nel mio controller asincrono e usando quello per creare un SimpMessagingTemplate.(Non puoi collegarlo direttamente perché avrai solo il modello che va al broker).

In metodi di sottoscrizione, ho quindi utilizzato il modello diretto mentre in altri metodi ho utilizzato il modello che è andato al broker.