Bug report #14589
GetCapabilities gets cached in a confusing way (even when QGIS cache is set to 0)
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
History
#1 Updated by Giovanni Manghi over 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 over 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 over 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 over 7 years ago
- Regression? set to Yes
#5 Updated by Giovanni Manghi over 7 years ago
- Priority changed from Severe/Regression to High
#6 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
#7 Updated by Giovanni Manghi over 7 years ago
- Description updated (diff)
- Affected QGIS version changed from 2.18.4 to 2.18.7
#8 Updated by Luigi Pirelli over 7 years ago
just evaluating the issue if I'm able to fix
#9 Updated by Luigi Pirelli over 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 over 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 over 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 over 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 7 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 about 7 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 about 7 years ago
- Status changed from Open to Feedback
#16 Updated by Giovanni Manghi about 7 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed/implemented