#11379 closed defect (fixed)
Flush Tile Cache Doesn't Work Completely
Reported by: | Owned by: | wiktorn | |
---|---|---|---|
Priority: | normal | Milestone: | 15.05 |
Component: | Core imagery | Version: | |
Keywords: | template_report | Cc: | wiktorn |
Description
What steps will reproduce the problem?
- Open JOSM, turn on Mapnik imagery, download some OSM data, make edit that will result in a rendering change to Mapnik, upload change to OSM.
- Wait enough time for rendering engine to render the change. Lately that has only been a couple of minutes.
- Right click on imagery, click "Flush Tile Cache"
What is the expected result?
Screen should be refreshed with up to date Mapnik tiles.
What happens instead?
Screen does flicker, but tiles do not reflect the rendering change, until, one opens www.openstreetmap.org, navigates the default map to the same area and zoom level as is shown in JOSM and hits F5. The new tiles then show up in the browser, and when I go back to JOSM and "Refresh Tile Cache" they then show up there as well. I know that the browser cache and the JOSM cache should not be connected, but it appears they they are. It could just be coincidence (it could be that on all my tests the rendering engine rendered my change right after I had given up in JOSM and right before I tried refreshing my browser), however I have run a number of tests, and it always works the way described here.
Please provide any additional information below. Attach a screenshot if possible.
For some reason in my imagery menu I have two Mapnik options. One is http: and the other https:. It doesn't matter which I use, the problem is the same, but since that is non standard, perhaps it has something to do with it.
Repository Root: http://josm.openstreetmap.de/svn Build-Date: 2015-04-28 01:31:11 Last Changed Author: Don-vip Revision: 8287 Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Relative URL: ^/trunk URL: http://josm.openstreetmap.de/svn/trunk Last Changed Date: 2015-04-28 01:11:18 +0200 (Tue, 28 Apr 2015) Last Changed Rev: 8287 Identification: JOSM/1.5 (8287 en) Windows XP 32-Bit Memory Usage: 185 MB / 247 MB (96 MB allocated, but free) Java version: 1.7.0_17, Oracle Corporation, Java HotSpot(TM) Client VM Dataset consistency test: No problems found Plugins: - DirectUpload (30892) - InfoMode (30892) - PicLayer (30962) - buildings_tools (31100) - dataimport (30892) - editgpx (30892) - ext_tools (30892) - fieldpapers (b49dadd) - geochat (31056) - jna (30892) - log4j (30892) - merge-overlap (30988) - photo_geotagging (30967) - turnrestrictions (31034) - utilsplugin2 (31072) - videomapping (30892) Last errors/warnings: - W: JCS - Silent failure during download: https://a.tile.openstreetmap.org/18/54678/98726.png - W: JCS - Exception during download https://a.tile.openstreetmap.org/18/54679/98723.png - W: JCS - Silent failure during download: https://a.tile.openstreetmap.org/18/54679/98723.png - W: JCS - Exception during download https://a.tile.openstreetmap.org/18/54679/98724.png - W: JCS - Silent failure during download: https://a.tile.openstreetmap.org/18/54679/98724.png
Attachments (0)
Change History (12)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Cc: | added |
---|
comment:3 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → needinfo |
Please also update your version of Java. 7u17 is a very old one.
comment:4 by , 10 years ago
Resolution: | → othersoftware |
---|---|
Status: | needinfo → closed |
It looks like the problem is, that the server did not regenerate the tile, but just gives you the cached version of the tile.
comment:5 by , 10 years ago
Yes, so perhaps this isn't a bug, but a feature request. Requesting that JOSM request that the server not send a cached version, similar to what a browser does when one presses <F5>
comment:6 by , 10 years ago
Milestone: | → 15.05 |
---|---|
Resolution: | othersoftware |
Status: | closed → reopened |
Then what I can do, is just to issue a request to server, to reload this tiles without any intermediary caches.
comment:7 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:9 by , 10 years ago
That's what Java sets, when URLConnection.setUseCache(false)
is used:
Cache-Control: no-cache Pragma: no-cache
follow-up: 11 comment:10 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
In 8424/josm, in [o31145]:
Set URLConnection.setUseCaches(false) when forcing reload of tiles. Closes #5717
I've closed with wrong message.
This sounds very peculiar.
There are debug commands to check the status of a tile rendering, e.g.:
http://c.tile.openstreetmap.org/18/136242/88065.png/status
and mark it dirty explicitly:
http://c.tile.openstreetmap.org/18/136242/88065.png/dirty
Please try to narrow down the problem a little more with these commands.