Qt World Summit: Submit your Presentation

Is multiple QNetworkAccessManager per process disrecommended?

  • I can see that Qt's recommendation is to have at most one QNetworkAccessManager instance.

    "One QNetworkAccessManager should be enough for the whole Qt application."

    "As a rule of thumb, the fewer instances of the QNetworkAccessManager, the better; the optimum is one instance per process (application)"

    https://bugreports.qt.nokia.com/browse/QTBUG-15359 (probably fixed in 4.8)
    "More than one QNetworkAccessManager in same process on Symbian does not work properly"

    However, we have a QDeclarativeNetworkAccessManagerFactory class, which implies that the QtDeclarative creates its own (separate) QNetworkAccessManager instance/s for fetching any urls present in the QML code. If I additionally use a QNetworkAccessManager in C++ to download some stuff, that would mean there's potentially more than one QNetworkAccessManager in the same process at the same time.

    Is multiple QNetworkAccessManager per process disrecommended?

    Do I have a problem if I get stuff from the net in both C++ code and in QML code (with a networkAccessManagerFactory() set)? If so, is there a recommended alternative scheme?


  • Use singleton class wrapper around QNetworkAccessManager.

  • @minimoog77: Presumably, you are suggesting that I implement my QDeclarativeNetworkAccessManagerFactory subclass such that it returns the same instance of QNetworkAccessManager in the create() method.

    My concerns about doing that are:

    1. The fact that the API is QDeclarativeEngine::setNetworkAccessManagerFactory() suggests that QtDeclarative would prefer to create multiple different instances of QNetworkAccessManager. If the trolls had thought that the same instance of QNetworkAccessManager would do fine, then the API would have been QDeclarativeEngine::setNetworkAccessManager().

    2. The QNetworkAccessManager::get() should ideally be called in the same thread as the one in which the QNetworkAccessManager object lives. This is because ::get() internally creates a QNetworkReply object with the QNetworkAccessManager as parent. If the QNetworkReply is created in a thread different from the one in which the QNetworkAccessManager object lives, it would result in problems like the one seen here: http://www.qtcentre.org/archive/index.php/t-35345.html

    As per http://doc.trolltech.com/qdeclarativenetworkaccessmanagerfactory.html:
    "Note the QML engine may create QNetworkAccessManager instances from multiple threads."

    So, if our QDeclarativeNetworkAccessManagerFactory returns the same instance of QNetworkAccessManager that lives in some thread t1, the QML can potentially use it from another thread t2, which can cause the said problem.

    Therefore, returning the same instance of QNetworkAccessManager in QDeclarativeNetworkAccessManagerFactory::create() is not an option.

  • Well, in my case, I am not using singleton aroung QNAM, I use singleton in the rest of my C++ code. Also I create new instance in QNetworkAccessManagerFactory. No problems so far for me in Symbian.

    So, bad advice from me. Sorry.

  • In my case, I've set a QNetworkAccessManagerFactory, and I'm using multiple other QNetworkAccessManager instances in the C++ code. I'm not really facing a problem with this in Symbian (@minimoog77: Thanks for confirming that you too don't.) I was only trying to check if there are any potential problems, given that the docs seem to discourage having multiple instances of QNAM. (Incidentally, I have problems if I use multiple instances of QNetworkAccessManager in the same thread.)

  • I think multiple instances problem of QNAM should be fixed in Qt 4.8. Anyway, it's rather confusing, which is pretty strange for Qt library.

Log in to reply