Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QGIS/Windows setting cache size to zero fails on certain WMS services #31056

Closed
rduivenvoorde opened this issue Aug 2, 2019 · 10 comments
Closed
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Feedback Waiting on the submitter for answers stale Uh oh! Seems this work is abandoned, and the PR is about to close.

Comments

@rduivenvoorde
Copy link
Contributor

Thanks Andrea for letting us know.
See also this thread on the mailinglist:
https://lists.osgeo.org/pipermail/qgis-user/2019-August/043569.html

On certain WMS services, there is an issue when the users has set the cache size of QGIS to 0 (zero).
I can only reproduce it on Windows though, both in 3.8 and master/3.9

To reproduce:

  • start QGIS 3.8 or 3.9
  • make sure you normal a valid cache setting
  • add a WMS-service with this public url:
    https://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/ows
  • now just add the layer 'provincies', you will see NL in all it's glory :-)
  • now open the network settings of QGIS and set the cache size to 0
    Screenshot-20190802150525-772x173
  • close the project, create a new one
  • go to your wms connections, connect to service above and try to load the same provincies layer
  • NOW you see an error (red message in the wms connection dialog)
    the logs tell you:
    2019-08-02T16:42:58 CRITICAL Invalid Layer : Raster layer Provider is not valid (provider: wms, URI: contextualWMSLegend=0&crs=EPSG:4326&dpiMode=7&featureCount=10&format=image/png&layers=provincies&styles&url=https://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/ows (file: ......srccorerasterqgsrasterlayer.cpp row: 614function QgsRasterLayer::setDataProvider:)

All this ONLY on windows, same service and QGIS versions on Linux work fine.

Making the cache size 1 already gives a valid result.

@rduivenvoorde rduivenvoorde added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Aug 2, 2019
@gioman
Copy link
Contributor

gioman commented Aug 3, 2019

@rduivenvoorde FYI, this problem (or a very similar one) is bugging us since... long. For example this was also an issue in 2.*

@rduivenvoorde
Copy link
Contributor Author

rduivenvoorde commented Aug 3, 2019

@gioman : a hacky way to 'fix' this is to make the size dropdown have a minimum >= 1
What do you mean by 'a similar one' ?
I think there has been some problems with the creation of the GetCapabilities url (if it contained or NOT contained something in the Query params) some versions ago. Which made QGIS give you about the same error. But I'm not aware of a real issue anymore besides this reproducable one.

@jef-n this is probably hard to debug isn't it? One because it occurs only on Windows, and Two because if I'm correct the caching mechanism used is deep-Qt specific?

I think the REAL problem is that people want the cache to be zero because they think/have problems which they think is because of the caching.
So another option would be to have a tickbox to just NOT have any network caching... (probably with some warning that this will really have performance results with wmts/tiled layers...)

@gioman
Copy link
Contributor

gioman commented Aug 3, 2019

What do you mean by 'a similar one' ?

well I remember clearly the following:

suppose you are creating a WMS service, and you are constantly fine tuning your advertised extent, layer list, etc. Then if you use QGIS as client you may want to have that cache set to "0", because you don't want it to make a (cached) request to a service that has changed in the meantime. Problem is (was?) that "0" means (meant?) "no limit" rather than "no cache", so the only solution is (was?) to constantly clear the cache with the "trash" button.

@jmckenna
Copy link
Contributor

jmckenna commented Aug 7, 2019

Can you add a tooltip in the "size" field saying "warning: changing the default cache size value may prevent parsing of some WMS/WFS/OGC services" ?

Personally I never change it, and instead use the "Clear Cache" button when needed.

@chau-intl
Copy link
Contributor

I'm testing WMTS performance and just ran into this issue on latest master. In my case I don't want QGIS to cache anything and by setting the cache size to 0 I was expecting to accomplish exactly this.

@gioman
Copy link
Contributor

gioman commented May 4, 2020

I'm testing WMTS performance and just ran into this issue on latest master. In my case I don't want QGIS to cache anything and by setting the cache size to 0 I was expecting to accomplish exactly this.

long standing issue, that bit me several times. As far as I have understand in the past 0 means "no limit" which is counter-intuitive/plain wrong.

@chau-intl
Copy link
Contributor

Maybe the entire caching configuration could use a little remake. It seems like people are expecting three options for caching:

  • None
  • All-you-can
  • A specific size.

I do however would like to see a more granular approach to caching. I would like to be able to adjust caching more individually. Especially I would like to be able to avoid clearing the cache for databases, since I have 30-50 schemas in a database and each schema has a lot of tables. Reloading this takes about half an hour - which is a very long time.

@Pedro-Murteira
Copy link

@rduivenvoorde Hello, is this issue still valid on more recent versions?

@gioman gioman added the Feedback Waiting on the submitter for answers label Mar 14, 2022
@github-actions
Copy link

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

@github-actions github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Mar 29, 2022
@github-actions
Copy link

While we hate to see this happen, this issue has been automatically closed because it has not had any activity in the last 42 days despite being marked as feedback. If this issue should be reconsidered, please follow the guidelines in the previous comment and reopen this issue.
Or, if you have any further questions, there are also further support channels that can help you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Feedback Waiting on the submitter for answers stale Uh oh! Seems this work is abandoned, and the PR is about to close.
Projects
None yet
Development

No branches or pull requests

5 participants