Closed
Description
Prashant Deva opened SPR-14703 and commented
This is the exception on server
Exception in thread "clientInboundChannel-97" org.springframework.messaging.MessageDeliveryException: Failed to handle GenericMessage [payload=byte[0], headers={simpMessageType=DISCONNECT, stompCommand=DISCONNECT, simpSessionAttributes={org.springframework.messaging.simp.SimpAttributes.COMPLETED=true}, simpSessionId=e4fb909754d849a08526503c2afa7584}] to org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask@329d23a5 in StompBrokerRelay[127.0.0.1:61613]; nested exception is java.lang.NullPointerException
at org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:144)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.springframework.messaging.simp.stomp.StompBrokerRelayMessageHandler$StompConnectionHandler.forward(StompBrokerRelayMessageHandler.java:783)
at org.springframework.messaging.simp.stomp.StompBrokerRelayMessageHandler.handleMessageInternal(StompBrokerRelayMessageHandler.java:511)
at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:238)
at org.springframework.messaging.support.ExecutorSubscribableChannel$SendTask.run(ExecutorSubscribableChannel.java:135)
... 3 more
Here is the client side code:
void setup() throws ExecutionException, InterruptedException
{
JettyWebSocketClient webSocketClient = new JettyWebSocketClient();
List<Transport> transports = new ArrayList<Transport>(1);
transports.add(new WebSocketTransport(webSocketClient));
SockJsClient sockJsClient = new SockJsClient(transports);
sockJsClient.setMessageCodec(new StringMessageCodec());
stompClient = new WebSocketStompClient(sockJsClient);
stompClient.setMessageConverter(new StringMessageConverter());
stompClient.start();
sessionHandler = new MyStompSessionHandler();
stompClient.connect(WS_URL, sessionHandler);
}
void stop()
{
stompSession.disconnect();
stompClient.stop();
}
As you can see the client closes the connection gracefully.
It first disconnects the session and then calls stop() on the stompClient.
Doing so should not result in an exception on the server.
Affects: 4.2.6
Issue Links:
- exception during websocket server shutdown [SPR-14716] #19281 exception during websocket server shutdown
Referenced from: commits 3bc1121, 07d5f8b, 114b2b6
Backported to: 4.2.8
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
spring-projects-issues commentedon Sep 13, 2016
Rossen Stoyanchev commented
Line number based on 4.2.6 should match to here.
Most likely the DISCONNECT frame and the closing of the websocket connection are competing with each other on the server-side. There is actually a way to wait for the DISONNECT to complete through a receipt header before shutting down completely. That said we should be more defensive around this scenario to avoid the NPE. I'll see if I can reproduce it easily. Either way I can add some checks.
spring-projects-issues commentedon Sep 14, 2016
Rossen Stoyanchev commented
This should now be fixed in snapshots of all 3 target versions.