QGIS » QGIS Application

I do not think this is totally right since after the first attempt (which fail) then things appears to be ok: IHMO there is some kind of init state condition concerning event loop which is not set on first run.

Anyway, runnig app.exec will defeat the purpose of embedding since it introduce a blocking state.

Alessandro Pasotti wrote:

Well, I don't really know what you're trying to do, but in QGIS application you do have a running main event loop and this is not an issue.

This is true for desktop. This is not true for server: in the fcgi implementation the main loop is a fcgi loop which is not related
to the QGIS application loop.

If you have a standalone non-GUI script that must run without an event loop you need a blocking condition or your script might terminate before the network reply comes back.

Yes

In any case you need an event loop (main or local).

Yes

Btw, in theory this whole thing should work without a main event loop because in the wms capabilities code there is a local event loop running, whose purpose is exactly to turn an asynchronous operation into a blocking one

Exactly

, what I don't understand is why it works the second time,

In fact, this is the way it should work in the normal way: as you said it, because of the the local event, it should not block the first time.

I believe that the answer is in Qt QNetworkAccessManager core code, I don't see any obvious issue in QgsNetworkAccessManager or in > the WMS code.

Me neither, I have spent some time to check the c++ code and I did not see anything suspicious.
Curiously, when I wrote a test case in python directly with the QNetworkAccessManager (and a local QEventLoop) to mimic what's in the
c++ code then it work flawlessly.

Just curious, was it working in 2.x ?

This has to be checked, and it has to be checked also in the fcgi implementation of the Qgis3 server.

I did some more research with different endpoints and I've discovered something really confusing, I now believe that we hit a Qt bug.
Here is my evidence:
I've tested several endpoints (qgis-server, geoserver and remote wms), this is the summary:
- qgis server on http://127.0.0.1 works
- qgis server (same as above) on http://localhost fails
- geoserver on a local docker with defined hostname fails
- geoserver on a local docker (same as above) with the docker IP works
- any remote hostname fails
- any remote IP address works

For example (same server):

        fails = 'contextualWMSLegend=0&crs=EPSG:4326&dpiMode=7&featureCount=10&format=image/png&layers=track_1&styles=&url=https://www.movimentolento.it/resource/wms/'
        works = 'contextualWMSLegend=0&crs=EPSG:4326&dpiMode=7&featureCount=10&format=image/png&layers=track_1&styles=&url=http://85.94.200.131/resource/wms/'

So, we can assume that there is something going bad with hostname resolution, every time I use the IP address it works and it fails when using the hostname (of course I verified with a browser that all the getcapabilities URLs were working).

Further info: a DNS look up prior to the connection works (Note: Since Qt 4.6.3 QHostInfo is using a small internal 60 second DNS cache for performance improvements.)

    def testLookup(self):
        self.loop = QEventLoop()
        def _p(info):
            self.loop.quit()
            self.assertTrue(info.addresses()[0].toString() == '85.94.200.130')
        QHostInfo.lookupHost('www.movimentolento.it', _p)
        self.loop.exec_()
        del(self.loop)
        # Without the DNS lookup the following fails
        self.layer = QgsRasterLayer(self.wmsuri_remote_ml_hostname, 'mywms', 'wms')
        self.assertTrue(self.layer.isValid())

Allessandro, thanks for investigating this.

So you think that it is related to DNS ?

For information, In my tests, wathever the url given in the first call but all subsequent call on différent hostname were successful: I have tested this by first calling with a 'localhost' - which has no wms service at all, but fail with timeout, then doing other calls to - say 'tiles.maps.eox.at' - are all successfull.

So could we have a scenario where the DNS resolver is not correctly available/initialized for network opération at the first call and available for all subsequent calls ?

So you think that it is related to DNS ?

I suspect it is related with QHostInfo::lookupHost() which is called by QAbstractSocketPrivate, there are a lot of signal-slot connections that being in a separate thread are probably bound to the GUI thread loop (which isn't running in our test cases) for a correct dispatch and delivery. Still this doesn't explain why subsequent calls on different hostnames works after the first fails.

For information, In my tests, wathever the url given in the first call but all subsequent call on différent hostname were successful: I have tested this by first calling with a 'localhost' - which has no wms service at all, but fail with timeout, then doing other calls to - say 'tiles.maps.eox.at' - are all successfull.
So could we have a scenario where the DNS resolver is not correctly available/initialized for network opération at the first call and available for all subsequent calls ?

I admit that I don't have a clear picture but yes, I think that DNS lookup initialization might be involved.

Would you please confirm that using an IP address instead of an hostname works?

I understand that this is just a workaround, but calling

QHostInfo.fromName('') # Yes: it also works whith empty/invalid URL

Could you please check again on current release?
Thanks.