QWebSocket server stalls after 2k connections

Delavega77

Hi all,

i just configured the websocket server from the example qt5.12 on linux machine ubuntu 18.04. I builded the echosslclient example as well and i tried to perform a loop to make 10k thousands connections. But after about 2k connections the cpu goes at 100% and no more connections is allowed. Moreover if i disconnect the clients already connected i see the event in the server and clients are disconnected, but if i try to connect again no event is triggered.
So i want figure out if it is some missing machine configuration (max tcp connection, ipconfig...) or it is something related to the qwebsocket server object.
Any suggestion/comment is appreciated.
Thank you Diego

raven-worx

@Delavega77
how do you test your connections exactly?
Did you try to attach a debugger at the state where no more connections are possible?

Delavega77

@raven-worx
Hi ,
i just logged the number of connection established on the server side and on client side i get the message when it is connected.
I also tried from qt ide in debug mode but when no more connections are possible nothing happens.
Please let me know if i can test more.
Thank you.

raven-worx

@Delavega77
what is the memory consumption at this time of your server application?

You wrote:

But after about 2k connections the cpu goes at 100% and no more connections is allowed.

At this time you can in the debugger press the PAUSE button and check the position the runtime currently is in. Maybe this gives a clue whats going on.
You might need to repeat this a few times until you get a state which helps giving some information.

Delavega77

@raven-worx

Hi,
I tried your suggestion and i found that is stalled qeventdispatcher_glib.cpp

Details:

bool QEventDispatcherGlib::processEvents(QEventLoop::ProcessEventsFlags flags)
{
    Q_D(QEventDispatcherGlib);

    const bool canWait = (flags & QEventLoop::WaitForMoreEvents);
    if (canWait)
        emit aboutToBlock();
    else
        emit awake();

    // tell postEventSourcePrepare() and timerSource about any new flags
    QEventLoop::ProcessEventsFlags savedFlags = d->timerSource->processEventsFlags;
    d->timerSource->processEventsFlags = flags;

    if (!(flags & QEventLoop::EventLoopExec)) {
        // force timers to be sent at normal priority
        d->timerSource->runWithIdlePriority = false;
    }

    bool result = g_main_context_iteration(d->mainContext, canWait);
    while (!result && canWait)
        result = g_main_context_iteration(d->mainContext, canWait);

    d->timerSource->processEventsFlags = savedFlags;

    if (canWait)
        emit awake();

    return result;
}

and here:

bool QEventDispatcherGlib::processEvents(QEventLoop::ProcessEventsFlags flags)
{
    Q_D(QEventDispatcherGlib);

    const bool canWait = (flags & QEventLoop::WaitForMoreEvents);
    if (canWait)
        emit aboutToBlock();
    else
        emit awake();

    // tell postEventSourcePrepare() and timerSource about any new flags
    QEventLoop::ProcessEventsFlags savedFlags = d->timerSource->processEventsFlags;
    d->timerSource->processEventsFlags = flags;

    if (!(flags & QEventLoop::EventLoopExec)) {
        // force timers to be sent at normal priority
        d->timerSource->runWithIdlePriority = false;
    }

    bool result = g_main_context_iteration(d->mainContext, canWait);
    while (!result && canWait)
        result = g_main_context_iteration(d->mainContext, canWait);

    d->timerSource->processEventsFlags = savedFlags;

    if (canWait)
        emit awake();

    return result;
}

Thank you

Delavega77

@raven-worx
Any idea?
Thank you

raven-worx

@Delavega77
hard to say.
The complete callstack would be more interesting. But even then the bug might be outside (anywhere before).