Provide mechanism for tracking failed messages in STOMP protocol support [SPR-10891]

[spring-projects-issues]

Rossen Stoyanchev opened SPR-10891 and commented

Perhaps an error channel to which anyone can subscribe. Error messages posted to that channel should indicate (1) in what component the message failed, the (2) the failed message, (3) an exception if available, and any other information that may be useful for filtering.

---

Affects: 4.0 M3

Issue Links:

• Support for @Valid in @MessageMapping annotated methods [SPR-11185] #15811 Support for @Valid in @MessageMapping annotated methods
• Customize STOMP ERROR frame [SPR-12732] #17329 Customize STOMP ERROR frame

2 votes, 5 watchers

[spring-projects-issues]

Brian Clozel commented

@Valid annotated method arguments that fail validation will throw a MethodArgumentNotValidException (exception caught by exception handlers).

[spring-projects-issues]

Artem Bilan commented

Another option send ERROR message directly from the AbstractMethodMessageHandler.processHandlerMethodException when resolver.resolveMethod(ex) returns null.

[spring-projects-issues]

Rossen Stoyanchev commented

Indeed if no @MessageExceptionHandler handles the exception we could at least send something back to the session where the message came from. In this case the StompSubProtocolHandler could send a STOMP ERROR frame to the client.

[spring-projects-issues]

Rossen Stoyanchev commented

On further thought I don't see much practical use:

• WebSocket side: StompSubProtocolHandler already turns exception into STOMP ERROR frames.
• @Controller side: there is an @MessageExceptionHandler mechanism.
• Sending to the broker via SimpMessagingTemplate: the "brokerChannel" is synchronous by default so a try-catch should work.
• Broker side: we close connections pro-actively when forwarding fails (broker relay) which only leaves messages sent downstream to WebSocket clients; however due to the ExecutorService hand-off at the "clientOutboundChannel" it's down to potential exceptions from a ChannelInterceptor.

In short the strategy is @MessageExceptionHandler for messages handled with controller methods as well as thrown messages from the SimpMessagingTemplate. For all other messages getting through without application code getting involved, we proactively close connections and/or send ERROR frames.