Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8156518

WebSocket.Builder.connectTimeout(long timeout, TimeUnit unit) implicitly affect websocket connection timeout

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b173
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        According the javadoc, the method is "
        Sets a timeout for the opening handshake.

        If the opening handshake is not finished within the specified timeout then buildAsync() completes exceptionally with a HttpTimeoutException.

        If the timeout is not specified then it's deemed infinite.
        "
        According with the test, it actually affects not only opening handshake but also the underlying connection.

        This is a snippet of code. I will attach a whole version too.

                CompletableFuture<WebSocket> future = WebSocket
                        .newBuilder(
                                URI_to_ws_endpoint,
                                A_Listener)
                        .connectTimeout(5, TimeUnit.SECONDS) //Specify connectTimeout for opening handshake
                        .buildAsync();
                WebSocket ws = future.get();
                //Make sure handshake succeeded
                ws.sendText("Hello");
                //Indicate how timeout affects
                Thread.sleep(6000);//Wait for a moment
                System.out.println("isClosed:" + ws.isClosed());
                ws.sendText("Hello again").get();

        isClosed() returns false.
        But it will throw following exception when trying to sendText:
        Caused by: java.nio.channels.ClosedChannelException^M
                at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(java.base@9-internal/SocketChannelImpl.java:272)^M
                at sun.nio.ch.SocketChannelImpl.write(java.base@9-internal/SocketChannelImpl.java:496)^M
                at java.net.http.PlainHttpConnection.write(java.httpclient@9-internal/PlainHttpConnection.java:139)^M
                at java.net.http.RawChannel.write(java.httpclient@9-internal/RawChannel.java:147)^M
                at java.net.http.WSWriter.completeWrite(java.httpclient@9-internal/WSWriter.java:96)^M
                at java.net.http.WSWriter.write(java.httpclient@9-internal/WSWriter.java:86)^M
                at java.net.http.WSMessageSender$1.visit(java.httpclient@9-internal/WSMessageSender.java:148)^M
                at java.net.http.WSMessageSender$1.visit(java.httpclient@9-internal/WSMessageSender.java:110)^M
                at java.net.http.WSOutgoingMessage$Text.accept(java.httpclient@9-internal/WSOutgoingMessage.java:57)^M
                at java.net.http.WSMessageSender.completeSend(java.httpclient@9-internal/WSMessageSender.java:104)^M
                at java.net.http.WSMessageSender.send(java.httpclient@9-internal/WSMessageSender.java:91)^M
                at java.net.http.WSMessagePublisher.react(java.httpclient@9-internal/WSMessagePublisher.java:89)^M
                at java.net.http.WSSignalHandler.lambda$new$1(java.httpclient@9-internal/WSSignalHandler.java:80)^M
                at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@9-internal/ThreadPoolExecutor.java:1158)^M
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@9-internal/ThreadPoolExecutor.java:632)

        I'm not sure if this is expected behavior. But it is indeed surprising.

        Not sure what is the method or policy to decide a websocket connection to be alive. Actually, I didn't find an timeout concept for the websocket in javadoc, except connectTimeout for opening handshake.

        I suppose it is related with the timeout specified in HttpRequest.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                prappo Pavel Rappo
                Reporter:
                xiaofeya Xiaofeng Yang
                Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: