Expose asynchronous message sending in WebSocketSession [SPR-14099]

[spring-projects-issues]

Venkata Satya Teja Siram opened SPR-14099 and commented

Is it possible to send async messages using spring websockets..
In javax websocket we can async messages using

Session.getAsyncRemote().sendText(String text)
Session.getBasicRemote().sendText();

But is it possible to extract remote endpoint using spring websockets and send async messages without using stomp/sockJS?

The configuration and the use case can be found at following url:
http://stackoverflow.com/questions/36318483/extracting-remote-endpoint-object-from-spring-websocket-session

---

Affects: 4.2.5

Reference URL: http://stackoverflow.com/questions/36318483/extracting-remote-endpoint-object-from-spring-websocket-session

Issue Links:

• Reactive WebSocket adapter layer [SPR-14527] #19096 Reactive WebSocket adapter layer
• Support nonblocking writing to Jetty Websocket with possibility to assign callback [SPR-15527] #20086 Support nonblocking writing to Jetty Websocket with possibility to assign callback

1 votes, 4 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

You can get to the native session:

javax.websocket.Session session = ((StandardWebSocketSession) webSocketSession).getNativeSession();

We don't expose sending messages asynchronously in WebSocketSession but it shouldn't be hard to add an async send that returns ListenableFuture. I'll give this a try for 4.3.

[spring-projects-issues]

Venkata Satya Teja Siram commented

I tried the above casting and sending the message.

It resulted in the following error:
java.lang.ClassCastException: org.springframework.web.socket.adapter.jetty.JettyWebSocketSession cannot be cast to org.springframework.web.socket.adapter.standard.StandardWebSocketSession

PS: We are using jetty server

Tried type casting as follows:
((JettyWebSocketSession) session).getNativeSession().getRemote().sendStringByFuture(message);

[spring-projects-issues]

Rossen Stoyanchev commented

Yes, for Jetty we are adapting directly to their own WebSocket API, no need to go through JSR-356.

[spring-projects-issues]

Rossen Stoyanchev commented

On a second thought this is a bit more work since the WebSocketSession hierarchy also includes the SockJS transports and also the client side.

[spring-projects-issues]

Jesus Zazueta commented

Adding one more vote here. In my case, I decided to forgo STOMP support, along with the broker, and implement my own message handler in order to translate and broadcast messages across a Hazelcast cluster. My problem was that the synchronous sending code of StandardWebSocketSession was missing payloads when sending more than one message from multiple threads (I'm using Undertow in my case).

Rossen's suggestion of accessing StandardWebSocketSession directly worked for me, since I was able to invoke getNativeSession().getAsyncRemote().sendText() on the native Undertow implementation. But it would indeed be useful to have access to a javax.websocket.Session instance in a more transparent manner.

Thanks!

[spring-projects-issues]

Rossen Stoyanchev commented

Jesus Zazueta, WebSocket session does not support concurrent access and this is something that comes from the underlying native technology (e.g. JSR-356). For STOMP messaging we use a ConcurrentWebSocketSessionDecorator, which is a public class that you can also use.

[spring-projects-issues]

Rossen Stoyanchev commented

Note also for anyone interested in asynchornous, non-blocking I/O that in 5.0, Spring WebFlux, spring-webflux module, provides WebSocket support that is asynchronous, non-blocking, with Reactive Streams back pressure. It can be used with Undertow, Tomcat, Jetty, but it in a WebFlux application (i.e. not Spring MVC).