Bug report #14589

GetCapabilities gets cached in a confusing way (even when QGIS cache is set to 0)

Added by Nicklas Avén almost 8 years ago. Updated over 6 years ago.

Status:Closed
Priority:High
Assignee:-
Category:Web Services clients/WMS
Affected QGIS version:2.18.9 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:22557

Description

When connecting to a wms-service you get a fresh GetCapabilities response.

But the, when you try to add the layer to the map some old cached information about the service is used.

This is a behavior I cannot understand and it is very confusing. I guess it is a bug since I cannot find any reason to do it this way.

My guess is that the response is cached for usage together with the already added layers, but then it is important that a new layer gets added with the fresh getcapabilities response fetched when connecting last time.

The behavior now is very confusing and difficult to understand at first glance, so debugging to find it out is a nightmare.

Here is a post at the mailing list discussing this, including links to others who had the same problem.
http://lists.osgeo.org/pipermail/qgis-developer/2016-March/042095.html


Related issues

Related to QGIS Application - Bug report #10634: WMS provider: Cannot calculate extent Closed 2014-06-18
Related to QGIS Application - Bug report #7712: qgis server master does not work on Windows(?) Closed 2013-04-25
Related to QGIS Application - Bug report #13762: Error accessing external WMS server -- WMS provider: Cann... Closed 2015-11-05
Related to QGIS Application - Bug report #13294: WMS extent/coordinates wrong on Windows Closed 2015-08-31

History

#1 Updated by Giovanni Manghi almost 8 years ago

  • OS version deleted (jessie)
  • Target version deleted (Version 2.14)
  • Operating System deleted (Debian)

see also #13762

#2 Updated by Giovanni Manghi about 7 years ago

  • Target version set to Version 2.18
  • Priority changed from Normal to Severe/Regression
  • Affected QGIS version changed from 2.14.0 to 2.18.4

This is still confirmed in 2.18.4. And worst is that happens even when cache size is set 0 in QGIS general options.

I raise the priority because this was NOT an issue in past releases: right now fine tuning a WMS service (so a lot of trials are needed on the client after changes on the server, both at a project/mapfile level as also in the web server) can become a nightmare.

#3 Updated by Giovanni Manghi about 7 years ago

  • Subject changed from GetCapabilities gets cached in a confusing way to GetCapabilities gets cached in a confusing way (even when QGIS cache is set to 0)

#4 Updated by Giovanni Manghi almost 7 years ago

  • Regression? set to Yes

#5 Updated by Giovanni Manghi almost 7 years ago

  • Priority changed from Severe/Regression to High

#6 Updated by Giovanni Manghi almost 7 years ago

  • Easy fix? set to No

#7 Updated by Giovanni Manghi almost 7 years ago

  • Description updated (diff)
  • Affected QGIS version changed from 2.18.4 to 2.18.7

#8 Updated by Luigi Pirelli almost 7 years ago

just evaluating the issue if I'm able to fix

#9 Updated by Luigi Pirelli almost 7 years ago

I analysed the qgis and qt (QNetworkDiskCache and related) code and I can't find any possible bug... I followed capability caching and caching reset debugging qgis, but I'm not able to replicate the wrong behaviour.
The clear cache button works correctly (clearing the cached metadata, not wiping the cache disk area because it's a generic cache mechanism not aware of kind of cache support). Btw, as tested by @GiovanniManghi, that he's able to replicate, the wipe of the cache disk area solve the anomaly.
A possible solution/workaround is to add a wipe button by side of clear button that allow the wipe of disk area.

#10 Updated by Giovanni Manghi almost 7 years ago

Luigi Pirelli wrote:

I analysed the qgis and qt (QNetworkDiskCache and related) code and I can't find any possible bug... I followed capability caching and caching reset debugging qgis, but I'm not able to replicate the wrong behaviour.
The clear cache button works correctly (clearing the cached metadata, not wiping the cache disk area because it's a generic cache mechanism not aware of kind of cache support). Btw, as tested by @GiovanniManghi, that he's able to replicate, the wipe of the cache disk area solve the anomaly.
A possible solution/workaround is to add a wipe button by side of clear button that allow the wipe of disk area.

give me some time and I'll put together a series of steps to replicate.
Anyway the problem exist and is undeniable... it has been source of several reports here... all "solved" by wiping the cache folder.

#11 Updated by Luigi Pirelli almost 7 years ago

I can't find a way to reproduce the error. The QgsNetworkAccessManager.instance().cache().clear() already clear the cache => no need to wipe the cache three structure.

I'll suspend the research waiting for a reproducible issue procedure

#12 Updated by Giovanni Manghi almost 7 years ago

  • Affected QGIS version changed from 2.18.7 to 2.18.9

I have sent Luigi the necessary infos (and a screencast) about how see/replicate the issue,.

#13 Updated by dr - over 6 years ago

Faced again with this issue in 2.18.10 with the same behaviour as I described year ago in #14396-4

#14 Updated by Giovanni Manghi over 6 years ago

Tested on 2.18.12 and master and it seems to behave much better now in case an underlying service has changed. It seems that now "0" as cache amount means really "0". Also it seems that the button to clear the cache (when >0) seems to work. On 2.18.12 is still unclear to me if the cache really expires after some time... but anyway it seems that (if >0) at least on QGIS 3 if the underlying service changes the request is done from scratch.

I suggest to change this issue to a new one asking to add a note in the docs (if not there already).

#15 Updated by Giovanni Manghi over 6 years ago

  • Status changed from Open to Feedback

#16 Updated by Giovanni Manghi over 6 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed/implemented

Also available in: Atom PDF