id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
23540	[PATCH] Hangs when downloading Bing imagery, but only the first time in a session	sebastic	team	"As reported by Andrew Chadwick in [https://bugs.debian.org/1065678 Debian Bug #1065678]:
> 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.
>
> {{{
> [...]
> 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]
> }}}
>
> If it’s the *second* time around (within some unknown number of minutes),
> JOSM does not hang, and goes on to print messages like
>
> {{{
> 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...
> }}}
>
> 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.

The workaround is to add the OSM Carto layer first, and then add the Bing layer.
"	defect	closed	normal	24.02	Core imagery	tested	fixed		a.t.chadwick@… GerdP