Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
Andrew Chadwick
a.t.chadwick at gmail.com
Fri Mar 8 20:30:25 GMT 2024
Package: josm
Version: 0.0.svn18969+dfsg-1
Severity: normal
X-Debbugs-Cc: a.t.chadwick at gmail.com
Dear Maintainer,
When JOSM is instructed to download Bing background satellite and aerial
imagery, it hangs the first time JOSM is launched on a day of map editing.
It seems to be a key caching issue. If JOSM is then killed, and
subsequently launched again, it downloads the Bing imagery just fine.
If enough time then elapses without launching JOSM, the situation repeats.
For me this is usually about a day, but the timeframe is probably a lot
shorter.
I would expect Bing background imagery to be downloaded fine every time,
without causing JOSM to hang.
## Minimal Steps to Reproduce
The hang will happen in all ordinary usage when Bing imagry is used, but in
order to rule out config files and settings, you can run JOSM as
$ JAVA_OPTS="-Djosm.home=/tmp/josmhome.$$" josm --skip-plugins --debug
This prevents it from loading your personal config file or any downloaded
plugins. As soon as the main interface loads, add a Bing layer using
Imagery → Bing aerial imagery
If this is the *first* time the josm.home location is being used (i.e. it
didn’t exist before), JOSM will then hang with the final debug messages
shown immediately below. JOSM then hangs and has to be killed with ^C or
using xkill.
-----------------------8<----------------------
[...]
2024-03-08 20:12:56.115 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:12:56.120 FINE: Contacting Server...
2024-03-08 20:12:56.120 FINE: REQUEST HEADERS: {Accept=*/*, Accept-Encoding=gzip, deflate}
2024-03-08 20:12:56.223 INFO: GET https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders&output=xml&key=...stripped... -> HTTP/1.1 200 (102 ms)
2024-03-08 20:12:56.223 FINE: RESPONSE HEADERS: {Transfer-Encoding=[chunked], null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], x-azure-ref=[20240308T201256Z-39saph36ah08xe5gfvn6y1z8pw000000083g0000000001pm], X-BM-TraceID=[cbf82a8a7dda1cbe233823c5d9cd1a91], Alt-Svc=[h3=":443"; ma=86400], Access-Control-Allow-Origin=[*], Access-Control-Allow-Methods=[POST, GET, OPTIONS], X-BM-FE-Elapsed=[5], Connection=[keep-alive], Access-Control-Allow-Headers=[Content-Type,X-FD-Features,X-FD-FLIGHT,PreferAnonymous], Date=[Fri, 08 Mar 2024 20:12:56 GMT], Cache-Control=[no-cache], X-AspNet-Version=[4.0.30319], X-BM-Srv=[mapsplatform-frontend-55b6b7bd84-p2lfw, DU00003064], Content-Encoding=[gzip], Vary=[Accept-Encoding], X-MS-BM-WS-INFO=[0], X-Powered-By=[ASP.NET], Content-Type=[application/xml; charset=utf-8]}
2024-03-08 20:12:56.223 FINE: Downloading data...
2024-03-08 20:12:56.224 INFO: Successfully loaded Bing attribution data.
[hangs, ^C]
----------------------->8----------------------
If it’s the *second* time around (within some unknown number of minutes),
JOSM does not hang, and goes on to print messages like
-----------------------8<----------------------
2024-03-08 20:17:01.005 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:17:01.033 FINE: Reading Bing logo from https://dev.virtualearth.net/Branding/logo_powered_by.png
2024-03-08 20:17:01.038 FINE: Contacting Server...
2024-03-08 20:17:01.039 FINE: REQUEST HEADERS: {Accept=*/*, Accept-Encoding=gzip, deflate}
2024-03-08 20:17:01.420 INFO: GET https://dev.virtualearth.net/Branding/logo_powered_by.png -> HTTP/1.1 200 (381 ms; 1.17 kB)
2024-03-08 20:17:01.420 FINE: RESPONSE HEADERS: {Accept-Ranges=[bytes], null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], Alt-Svc=[h3=":443"; ma=86400], Cache-Control=[max-age=86400], ETag=["1da6b47d7e7e12e"], Last-Modified=[Thu, 29 Feb 2024 19:45:27 GMT], X-Azure-Ref=[0PXLrZQAAAABRV4dQ4FinSYsXKjq3EwHuTE9OMjFFREdFMTgxMgBmMTI3MDYwYi1mNDk4LTRlMjAtYjVkZi1hZWIyMzczZWM5NWU=], Content-Length=[1198], Date=[Fri, 08 Mar 2024 20:17:00 GMT], Content-Type=[image/png]}
2024-03-08 20:17:01.421 FINE: Downloading data...
2024-03-08 20:17:01.480 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.484 FINE: zoomChanged(): 2
2024-03-08 20:17:01.580 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.629 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-08 20:17:01.631 INFO: Allocate for tile source layer: 116 MB of memory. Available: 3 914 MB.
2024-03-08 20:17:01.644 FINE: zoomChanged(): 14
2024-03-08 20:17:01.645 FINE: JCS - Submitting job for execution for url: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.646 FINE: JCS - Submitting job for execution for url: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t1.tiles.virtualearth.net/tiles/a12222222222222.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - starting fetch of url: https://ecn.t1.tiles.virtualearth.net/tiles/a12222222222222.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t1.tiles.virtualearth.net/tiles/a21111111111111.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - starting HttpClient GET request for URL: https://ecn.t2.tiles.virtualearth.net/tiles/a30000000000000.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.647 FINE: JCS - Submitting job for execution for url: https://ecn.t3.tiles.virtualearth.net/tiles/a30000000000002.jpeg?g=14355&pr=odbl
2024-03-08 20:17:01.648 FINE: Contacting Server...
----------------------->8----------------------
And so on. The program is now fully usable.
I would guess this is a cache directory liveness issue. That’s because the
misbehaviour can also be provoked by deleting JOSM’s cache (which is
normally ~/.cache/JOSM) before launching JOSM with your normal prefs,
plugins, and presets. JOSM will then hang regardless of when it’s launched:
the hang happens when JOSM is doing its Bing cache initialization or a full
refresh (perhaps some magic numbers for the service?)
The workaround is to launch JOSM and try and download Bing imagery, let it
hang, then kill it and start it again. A bit annoying to have to do before
each editing session, but it works.
thanks for maintaining,
Andrew
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages josm depends on:
ii default-jre [java9-runtime] 2:1.17-75
ii fonts-noto 20201225-2
ii jmapviewer 2.19+dfsg-1
ii libcommons-compress-java 1.25.0-1
ii libgettext-commons-java 0.9.6-6
ii openjdk-17-jre [java9-runtime] 17.0.10+7-1
ii openjfx 11.0.11+1-3.1
ii proj-data 9.3.1-1
Versions of packages josm recommends:
ii josm-l10n 0.0.svn18969+dfsg-1
josm suggests no packages.
-- Configuration Files:
/etc/default/josm changed:
-- no debconf information
More information about the Pkg-grass-devel
mailing list