0

I have a WebServerSocket opened and sending a test message out to a client, and I'm testing the behaviour when the connection dies, and things aren't behaving as I would have expected/hoped. After I have have a connection opened from a client, I then proceed to manually kill the client (to ensure the connection is dead), and then execute something like this:

webServerSocket.writeTextMesage("are you still there?")
    .onComplete(ar -> { 
        if (ar.succeeded()) {
            System.out.println("success"); 
        } else if (ar.failed()) {
             System.out.println("failure"); 
        }
    );

I'm expecting the failure message to be executed since I know that I've already killed the connection, but in fact the success message is hit instead. Digging a little I notice that the ConnectionBase instance being used is set to "read" mode when the socket tries to write the message, and this in turn causes no flush to happen. Waiting a little longer, and generating more outgoing traffic on the socket, I observe that the socket will eventually trigger a flush at which point a failure is indeed triggered. But what can I do to ensure that I receive a failure at the precise point above, when the connection is certainly already dead?

Paul Galbraith
  • 128
  • 1
  • 10
  • Websockets are sticky, so killing the client might not guarantee immediately dies. Some time is probably needed to gracefully close the socket. Maybe also look https://stackoverflow.com/questions/409783/socket-shutdown-vs-socket-close – Tcheutchoua Steve Jun 10 '21 at 19:06
  • Interesting, thanks for the comment. I would have expected that there would be some way to confirm at least a final tcp ack received from a given outbound message, at least optionally, when "transactional" boundaries of sort may need to be identified and confirmed. – Paul Galbraith Jun 11 '21 at 00:23

0 Answers0