Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-85212

QWebsocket::open Never Resolves with an Unresponsive Server

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reported
    • Priority: P2: Important
    • Resolution: Unresolved
    • Affects Version/s: 5.14.1
    • Fix Version/s: None
    • Component/s: WebSockets
    • Labels:
      None
    • Environment:
      CentOS7 using "ws://localhost:5000"
    • Platform/s:
      Linux/X11

      Description

      I have a websocket server that simply stores the connected client, and appends any text received to a text edit control.

      I created a manual test to put some load on my server, in order to see how it would behave, and try to get a send call to return anything aside from the number of bytes I gave it. My mission was to get a better understanding of how send handles errors.

      My test would

      • load a 1 mb text file
      • connect to my server
      • when signaled that it was connected, post a function that calls send with the contents of the text file, using QMetaObject::invokeMethod

      In the function where the send occurred, I'd post again, if my number of iterations was less than 10,000.

      So, in effect, I slammed my server with 10,000 sends of 1MB of text.
      It does not surprise me that the server stopped responding. It would not error out or crash, but just hang in the text edit's layoutBlock forever.

      Note that is not the bug I am reporting. I am just describing setup.

      What I am concerned about, is that if I would attempt to run my test a second time, any call to QWebsocket::open would never resolve. I did not get a connection refused. I did not get signaled that I was connected. If I paused my program in the debugger, it was just sitting in the event loop forever, I assume waiting for some internal event.

      The state of the server should have no effect on the entirely separate client process. I'd expect the client to either report an error or connect.

      The API does not have a means to specify a timeout.

      The end result is that I can potentially have clients in production that give the appearance of a hung process, because they never error out, but never connect either.

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            kurt.pattyn Kurt Pattyn
            Reporter:
            fleshbits Christopher Pisz
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:

                Gerrit Reviews

                There are no open Gerrit changes