This is an issue I have with websockets where connecting to a websocket hangs. The server is using a self-signed certificate, which has been already imported to the cacerts. Java code can make https requests without any issues regarding the certificate. When writing a client to listen updates from a websocket, the client never connects and hangs forever.
WebSocketClient client = new StandardWebSocketClient();
WebSocketStompClient stompClient = new WebSocketStompClient(client);
StompSessionHandler handler = new StompSessionHandler() {
@Override
public void handleFrame(StompHeaders headers, Object payload) {
System.err.println("handleFrame");
}
@Override
public Type getPayloadType(StompHeaders headers) {
return String.class;
}
@Override
public void handleTransportError(StompSession session, Throwable exception) {
System.err.println("handleTransportError");
}
@Override
public void handleException(StompSession session, StompCommand command, StompHeaders headers, byte[] payload, Throwable exception) {
System.err.println("handleException");
}
@Override
public void afterConnected(StompSession session, StompHeaders connectedHeaders) {
System.err.println("afterConnected");
}
};
CompletableFuture<StompSession> connectAsync = stompClient.connectAsync("wss://localhost:5000/ws/", handler);
connectAsync.get();
System.err.println("Connected");
Thread.sleep(10000000);
I never see the print statement that say Connected or the print statements inside StompSessionHandler.
I am checking the server logs, and the server say that the handshake has been established and a connection is made. Furthermore I have enabled -Djavax.net.debug=all and I can see the updates and new messages from the websocket being printed in the logs.
javax.net.ssl|DEBUG|E3|WebSocketClient-SecureIO-2|2023-08-08 13:39:21.958 PDT|SSLEngineInputRecord.java:213|READ: TLSv1.2 application_data, length = 63
javax.net.ssl|DEBUG|E3|WebSocketClient-SecureIO-2|2023-08-08 13:39:21.958 PDT|SSLCipher.java:1675|Plaintext after DECRYPTION (
0000: 82 25 7B 22 74 6F 70 69 63 22 3A 22 73 79 73 74 .%."topic":"syst
0010: 65 6D 22 2C 22 68 62 22 3A 31 36 39 31 35 32 37 em","hb":1691527
0020: 31 36 31 38 33 30 7D 161830.
)
So Im guessing the client is in fact connecting but somehow facing issues that never confirms there is a connection.
Dependencies used:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.1.2</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-websocket</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-messaging</artifactId>
</dependency>
Update: Im changing the spring-boot version to 3.0.9 and I'm getting these logs:
14:08:57.642 [main] DEBUG org.springframework.web.socket.client.standard.StandardWebSocketClient -- Connecting to wss://localhost:5000/ws/
14:08:57.810 [SimpleAsyncTaskExecutor-1] DEBUG org.springframework.web.socket.handler.LoggingWebSocketHandlerDecorator -- New StandardWebSocketSession[id=c2fac7af-4d89-39a2-ccde-9e3c6d7e73ea, uri=null]
14:08:57.810 [SimpleAsyncTaskExecutor-1] DEBUG org.springframework.messaging.simp.stomp.DefaultStompSession -- Connection established in session id=ba753728-c5db-a6a1-8da8-8722d448745c
However, I'm still not seeing the print statements.
Additionally, I'm able to correctly connect to the websocket and read the messages using the following code:
WebSocketContainer container = ContainerProvider.getWebSocketContainer();
Session session = container.connectToServer(HandlerClient.class, URI.create("wss://localhost:5000/ws/"));
Thread.sleep(1000000);
As well as with Insomia and Python client. At this point I dont think that the problem is with the Server.
Comment From: mmartinekTX
We are seeing the same as well with websocket (StandardWebSocketClient) and SSL. Unfortunately, the above approach of using the WebSocketContainer didn't prove successful for us.
On the websocket server side we see the following exception: `2023-08-10T10:44:37.656-05:00 DEBUG 26608 --- [ XNIO-1 I/O-8] io.undertow.request : UT005013: An IOException occurred
java.net.SocketException: Connection reset at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394) ~[na:na] at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426) ~[na:na] at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:289) ~[xnio-nio-3.8.8.Final.jar:3.8.8.Final] at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:748) ~[undertow-core-2.3.7.Final.jar:2.3.7.Final] at io.undertow.protocols.ssl.SslConduit.doHandshake(SslConduit.java:672) ~[undertow-core-2.3.7.Final.jar:2.3.7.Final] at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1240) ~[undertow-core-2.3.7.Final.jar:2.3.7.Final] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) ~[xnio-nio-3.8.8.Final.jar:3.8.8.Final] at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) ~[xnio-nio-3.8.8.Final.jar:3.8.8.Final]`
On the client side we receive a "Connection timed out" error, but the connection is actually successful. The SSL handshake seems to never occur, it sits in a select() loop until the connection timeout is exceeded.
Other clients are connecting fine, just not Spring clients after upgrading.
Comment From: mmartinekTX
@ek-ex After much troubleshooting, I found a couple things that resolved this for us: 1. Our registerWebSocketHandlers was adding a path of "/socket.io/" which used to work, but I had to change it to "/socket.io/". 2. I noticed in SSL trace output that it negotiated TLSv1.3 but communicating in TLSv1.2. In our application.properties we added server.ssl.enabled-protocols=TLSv1.1,TLSv1.2*, and then websockets started working again.
With that sorted out, I can go back and fine tune it (see if we can just force TLSv1.3 for all services, so no downgrades are attempted). Hope this helps your case.