1

We are facing timing problems with QNetworkAccessManager and QTimers for network timeout detection. Though, its not clear to us, when to start these QTimers.

Our first try was to start the timer directly after the get request. But this leads to premature aborts under high load. Apparently QNetworkAccessManager does its own queuing and the timeout fires before it even puts the request on the wire.

QNetworkReply *reply = _qnam->get(someRequest);

// connect standard handlers of our application
QObject::connect(reply, &QNetworkReply::finished, [reply] {
    handle(reply);
});

// do timeout handling using QTimers in "global" scope
timeoutTimer.setSingleShot(true);
QObject::connect(&timeoutTimer, &QTimer::timeout, [reply] { reply->abort(); });
timeoutTimer.start(timeout);

The second try was to start the timer inside the first QNetworkAccessManager::uploadProgress() or QNetworkAccessManager::uploadProgress(), but this doesn't work in absence of any network connectivity. Obviously there is never any progress to report and the timeout isn't started in the first place.

QNetworkReply *reply = _qnam->get(someRequest);

// connect standard handlers of our application
QObject::connect(reply, &QNetworkReply::finished, [reply] {
    handle(reply);
});

// do timeout handling using QTimers in "global" scope
auto timerSetOrReset = [reply] {
    if (!timeoutTimer.isActive()) {
        timeoutTimer.setSingleShot(true);
        QObject::connect(&timeoutTimer, &QTimer::timeout, [reply] { reply->abort(); });
    }

    timeoutTimer.start(timeout);
};

QObject::connect(reply, &QNetworkReply::uploadProgress,   timerSetOrReset);
QObject::connect(reply, &QNetworkReply::downloadProgress, timerSetOrReset);

Feels like we cannot be the first ones to face this problem.

Thanks!

0 Answers0