Context Navigation

Modify ↓

#23540 closed defect (fixed)

[PATCH] Hangs when downloading Bing imagery, but only the first time in a session

Reported by:	sebastic	Owned by:	team
Priority:	normal	Milestone:	24.02
Component:	Core imagery	Version:	tested
Keywords:		Cc:	a.t.chadwick@…, GerdP

Description

As reported by Andrew Chadwick in 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.

Attachments (2)

debug-logging-failure.txt (2.3 KB ) - added by sebastic 2 months ago.
debug-logging-success.txt (152.4 KB ) - added by sebastic 2 months ago.

Download all attachments as: .zip

Change History (18)

follow-up: 3 comment:1 by achadwick, 2 months ago

The workaround is to add the OSM Carto layer first, and then add the Bing layer.

This, unfortunately, does not work. The only workaround with Debian's build (JOSM/1.5 (18969 Debian en_GB) Linux Debian GNU/Linux trixie/sid) [EDIT:] is to kill and restart JOSM within a few minutes. After that: working layers.

JAVA_OPTS="-Djosm.home=/tmp/josmhome.$$" josm --skip-plugins --debug
[... it's the first time that josmhome.<shell-pid> folder exists ...]
[...]
2024-03-09 13:15:50.403 FINE: JCS - downloaded key: OpenStreetMap Carto (Standard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/4/6/12, length: 206, url: https://tile.openstreetmap.org/4/6/12.png
2024-03-09 13:15:50.403 FINE: tileLoadingFinished() tile: Tile 4/5/12@OpenStreetMap Carto (Standard) [loaded] success: true
2024-03-09 13:15:50.403 FINE: tileLoadingFinished() tile: Tile 4/10/12@OpenStreetMap Carto (Standard) [loaded] success: true
2024-03-09 13:15:50.404 FINE: tileLoadingFinished() tile: Tile 4/5/6@OpenStreetMap Carto (Standard) [loaded] success: true
2024-03-09 13:15:50.405 FINE: zoomChanged(): 2
2024-03-09 13:15:50.405 FINE: tileLoadingFinished() tile: Tile 4/6/12@OpenStreetMap Carto (Standard) [loaded] success: true
2024-03-09 13:15:50.466 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-09 13:15:50.568 INFO: AbstractTileSourceLayer: estimated visible tiles: 54, estimated cache size: 466
2024-03-09 13:15:54.109 FINE: Unsupported savable layer type: TMSLayer
2024-03-09 13:15:54.111 FINE: Contacting Server...
2024-03-09 13:15:54.111 FINE: REQUEST HEADERS: {Accept=*/*, Accept-Encoding=gzip, deflate}
2024-03-09 13:15:54.259 INFO: GET https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders&output=xml&key=...stripped... -> HTTP/1.1 200 (147 ms)
2024-03-09 13:15:54.259 FINE: RESPONSE HEADERS: {Transfer-Encoding=[chunked], null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], x-azure-ref=[20240309T131554Z-9tusp1hxvd6pf2zgvzk9tqadvn00000001g0000000014ubg], X-BM-TraceID=[02503c1637c0b3a6c28c9542402c8802], Alt-Svc=[h3=":443"; ma=86400], Access-Control-Allow-Origin=[*], Access-Control-Allow-Methods=[POST, GET, OPTIONS], X-BM-FE-Elapsed=[6], Connection=[keep-alive], Access-Control-Allow-Headers=[Content-Type,X-FD-Features,X-FD-FLIGHT,PreferAnonymous], Date=[Sat, 09 Mar 2024 13:15:54 GMT], Cache-Control=[no-cache], X-AspNet-Version=[4.0.30319], X-BM-Srv=[mapsplatform-frontend-55b6b7bd84-8ckj6, DU00003074], 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-09 13:15:54.259 FINE: Downloading data...
2024-03-09 13:15:54.260 INFO: Successfully loaded Bing attribution data.
[... hangs ...]
^C2024-03-09 13:17:09.513 FINE: Shutdown hook activated. Shutdown was not called. Shutting down JCS.

Last edited 2 months ago by achadwick (previous) (diff)

comment:2 by achadwick, 2 months ago

@sebastic

This issue is not reproducible with the current josm-tested.jar from https://josm.openstreetmap.de/ when it is launched with the same or similar parameters:

$ java -Djosm.home=/tmp/josmhome.vers.$$ -jar ./josm-tested.jar --skip-plugins --debug --version
2024-03-09 13:27:08.667 FINE: lsb_release -i -s
JOSM/1.5 (18969 en_GB) Linux Debian GNU/Linux trixie/sid
$ rm -vfr /tmp/josmhome.*
$ java -Djosm.home=/tmp/josmhome.vers.$$ -jar ./josm-tested.jar --skip-plugins --debug
[... downloads Bing tiles straight away, no hang, exits cleanly ...]

I will investigate further, looking at what the Debian wrapper scripts do, because they change the runtime environment somewhat.

in reply to: 1 comment:3 by sebastic, 2 months ago

Replying to achadwick:

The workaround is to add the OSM Carto layer first, and then add the Bing layer.

This, unfortunately, does not work.

It works me using josm (0.0.svn18969+dfsg-1) on Debian unstable.

JCS was updated in 18940 (specifically r18909), it may be caused by those changes.

comment:4 by achadwick, 2 months ago

This is reproducible (by me) when invoking the jarfile in Debian's josm 0.0.svn18969+dfsg-1 directly. It must be a repack for DFSG compliance:

$ sha256sum /usr/share/josm/*.jar ~/tmp/josm-tested.jar 
32542451ab3c6eb5368beffb4970920f2d6efcbdaa2dd7f02eff5677b99cd49e  /usr/share/josm/josm-0.0.svn18969+dfsg.jar
32542451ab3c6eb5368beffb4970920f2d6efcbdaa2dd7f02eff5677b99cd49e  /usr/share/josm/josm.jar
6bc9ae470138fbd59d615cfb95813d7519ea548190c4bf1c16621d06bd91eb95  /home/andrewc/tmp/josm-tested.jar

$ ls -l /usr/share/josm/*.jar ~/tmp/josm-tested.jar
-rw-r--r-- 1 andrewc andrewc 16856669 Mar  9 13:20 /home/andrewc/tmp/josm-tested.jar
-rw-r--r-- 1 root    root    15785791 Feb  6 13:55 /usr/share/josm/josm-0.0.svn18969+dfsg.jar
lrwxrwxrwx 1 root    root          26 Feb  6 13:55 /usr/share/josm/josm.jar -> josm-0.0.svn18969+dfsg.jar

$ java -Djosm.home=/tmp/josmhome.debian-jar.$$ -jar /usr/share/josm/josm.jar --skip-plugins --debug
[... you all know what happens now.
     It hangs the first time, succeeds after ^C when re-invoked
     within a few minutes. Probably it would be reproducible after
     the cache it's trying to update expires (I guess)
...]

This is a bug with the Debian packaging, and I will continue this discussion on the Debian bug tracker and not here.

comment:5 by GerdP, 2 months ago

Milestone:	24.02
Resolution:	→ othersoftware
Status:	new → closed

by sebastic, 2 months ago

Attachment:	debug-logging-failure.txt added

by sebastic, 2 months ago

Attachment:	debug-logging-success.txt added

comment:6 by sebastic, 2 months ago

Resolution:	othersoftware
Status:	closed → reopened

I would like some help to troubleshoot this.

The Debian package uses the same version of dependencies as the upstream builds, with the exception of xmpcore which only has source JARs for 6.1.10 whereas the metadata-extractor JAR on Maven Central uses the built classes from 6.1.11. The Debian package builds all the Java code from source instead of using the JARs from Maven Central like the upstream build does.

Another significant difference is that the Debian package is built with JDK 17 whereas josm-tested.jar seems to built with JDK 8 still.

I don't know how to further troubleshoot this.

The --debug output from a failure shows no JCS logging: debug-logging-failure.txt

The JCS logging is included when the Bing layer is added successfully: debug-logging-success.txt
But then it does not include the "Successfully loaded Bing attribution data" logging.

This might be related to the jmapviewer Debian package not including bing_maps.png due to copyright issues.
getAttributionImage() should still handle this case, though.

follow-up: 8 comment:7 by taylor.smock, 2 months ago

Assuming I correctly reproduced a minimal classpath (java -cp jmapviewer.jar:josm.jar:commons-compress.jar org.openstreetmap.josm.gui.MainApplication), the problem is that there is a deadlock. If I replace jmapviewer.jar with one I've built locally, everything works properly.

Relevant parts of the dump:

"AWT-EventQueue-0" prio=0 tid=0x0 nid=0x0 waiting on condition
     java.lang.Thread.State: WAITING
 on java.util.concurrent.FutureTask@661f272d
	at java.base@21.0.2/jdk.internal.misc.Unsafe.park(Native Method)
	at java.base@21.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:221)
	at java.base@21.0.2/java.util.concurrent.FutureTask.awaitDone(FutureTask.java:500)
	at java.base@21.0.2/java.util.concurrent.FutureTask.get(FutureTask.java:190)
	at app//org.openstreetmap.gui.jmapviewer.tilesources.BingAerialTileSource.getAttribution(BingAerialTileSource.java:289)
	at app//org.openstreetmap.gui.jmapviewer.tilesources.BingAerialTileSource.getAttributionImage(BingAerialTileSource.java:226)
	at app//org.openstreetmap.gui.jmapviewer.AttributionSupport.initialize(AttributionSupport.java:44)
	at app//org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.initTileSource(AbstractTileSourceLayer.java:285)
	at app//org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.initializeIfRequired(AbstractTileSourceLayer.java:585)
	at app//org.openstreetmap.josm.gui.layer.AbstractTileSourceLayer.attachToMapView(AbstractTileSourceLayer.java:561)
	at app//org.openstreetmap.josm.gui.MapView.layerAdded(MapView.java:349)
	at app//org.openstreetmap.josm.gui.layer.LayerManager.fireLayerAdded(LayerManager.java:459)
	at app//org.openstreetmap.josm.gui.layer.LayerManager.realAddLayer(LayerManager.java:234)
	at app//org.openstreetmap.josm.gui.layer.MainLayerManager.realAddLayer(MainLayerManager.java:327)
	at app//org.openstreetmap.josm.gui.layer.LayerManager.lambda$addLayer$0(LayerManager.java:218)
	at app//org.openstreetmap.josm.gui.layer.LayerManager$$Lambda/0x000000013052eca0.run(Unknown Source)
	at app//org.openstreetmap.josm.gui.util.GuiHelper.runInEDTAndWaitWithException(GuiHelper.java:247)
	at app//org.openstreetmap.josm.gui.layer.LayerManager.addLayer(LayerManager.java:218)
	at app//org.openstreetmap.josm.gui.layer.LayerManager.addLayer(LayerManager.java:207)
	at app//org.openstreetmap.josm.actions.AddImageryLayerAction.actionPerformed(AddImageryLayerAction.java:170)
	at java.desktop@21.0.2/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
	at java.desktop@21.0.2/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2314)
	at java.desktop@21.0.2/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:407)
	at java.desktop@21.0.2/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
	at java.desktop@21.0.2/javax.swing.AbstractButton.doClick(AbstractButton.java:374)
	at java.desktop@21.0.2/com.apple.laf.ScreenMenuItem.actionPerformed(ScreenMenuItem.java:129)
	at java.desktop@21.0.2/java.awt.MenuItem.processActionEvent(MenuItem.java:692)
	at java.desktop@21.0.2/java.awt.MenuItem.processEvent(MenuItem.java:651)
	at java.desktop@21.0.2/java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:378)
	at java.desktop@21.0.2/java.awt.MenuComponent.dispatchEvent(MenuComponent.java:367)
	at java.desktop@21.0.2/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:778)
	at java.desktop@21.0.2/java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.desktop@21.0.2/java.awt.EventQueue$4.run(EventQueue.java:714)
	at java.base@21.0.2/java.security.AccessController.executePrivileged(AccessController.java:778)
	at java.base@21.0.2/java.security.AccessController.doPrivileged(AccessController.java:400)
	at java.base@21.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.base@21.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:98)
	at java.desktop@21.0.2/java.awt.EventQueue$5.run(EventQueue.java:747)
	at java.desktop@21.0.2/java.awt.EventQueue$5.run(EventQueue.java:745)
	at java.base@21.0.2/java.security.AccessController.executePrivileged(AccessController.java:778)
	at java.base@21.0.2/java.security.AccessController.doPrivileged(AccessController.java:400)
	at java.base@21.0.2/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.desktop@21.0.2/java.awt.EventQueue.dispatchEvent(EventQueue.java:744)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop@21.0.2/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

"bing-attribution-loader" prio=0 tid=0x0 nid=0x0 blocked
     java.lang.Thread.State: BLOCKED
 on org.openstreetmap.josm.gui.layer.MainLayerManager@3b46fff0 owned by "AWT-EventQueue-0" Id=35
	at app//org.openstreetmap.josm.gui.layer.MainLayerManager.getActiveDataSet(MainLayerManager.java:489)
	at app//org.openstreetmap.josm.gui.dialogs.ValidatorDialog.preferenceChanged(ValidatorDialog.java:743)
	at app//org.openstreetmap.josm.data.Preferences.lambda$firePreferenceChanged$2(Preferences.java:306)
	at app//org.openstreetmap.josm.data.Preferences$$Lambda/0x0000000130440800.fire(Unknown Source)
	at app//org.openstreetmap.josm.tools.ListenerList.fireEvent(ListenerList.java:155)
	at app//org.openstreetmap.josm.data.Preferences.firePreferenceChanged(Preferences.java:306)
	at app//org.openstreetmap.josm.data.Preferences.putSetting(Preferences.java:720)
	at app//org.openstreetmap.josm.spi.preferences.AbstractPreferences.put(AbstractPreferences.java:40)
	at app//org.openstreetmap.josm.spi.preferences.AbstractPreferences.putInt(AbstractPreferences.java:70)
	at app//org.openstreetmap.josm.io.CacheCustomContent.updateForce(CacheCustomContent.java:133)
	at app//org.openstreetmap.josm.io.CacheCustomContent.loadFromDisk(CacheCustomContent.java:185)
	at app//org.openstreetmap.josm.io.CacheCustomContent.getData(CacheCustomContent.java:154)
	at app//org.openstreetmap.josm.io.CacheCustomContent.getDataString(CacheCustomContent.java:165)
	at app//org.openstreetmap.josm.io.CacheCustomContent.updateIfRequiredString(CacheCustomContent.java:122)
	at app//org.openstreetmap.josm.data.imagery.CachedAttributionBingAerialTileSource.lambda$getAttributionLoaderCallable$0(CachedAttributionBingAerialTileSource.java:88)
	at app//org.openstreetmap.josm.data.imagery.CachedAttributionBingAerialTileSource$$Lambda/0x0000000130618b40.call(Unknown Source)
	at java.base@21.0.2/java.util.concurrent.FutureTask.run(FutureTask.java:317)
	at java.base@21.0.2/java.lang.Thread.runWith(Thread.java:1596)
	at java.base@21.0.2/java.lang.Thread.run(Thread.java:1583)

Last edited 2 months ago by taylor.smock (previous) (diff)

in reply to: 7 comment:8 by sebastic, 2 months ago

Replying to taylor.smock:

Assuming I correctly reproduced a minimal classpath (java -cp jmapviewer.jar:josm.jar:commons-compress.jar org.openstreetmap.josm.gui.MainApplication), the problem is that there is a deadlock. If I replace jmapviewer.jar with one I've built locally, everything works properly.

Does your jmapviewer.jar also work when it does not include bing_maps.png?

I've hacked up a build of the jmapviewer package to reinstate bing_maps.png, josm built and running with that does not hang when adding the Bing layer immediately after startup.

This suggest the BingAerialTileSource.java changes in JMapviewer 2.18 as a likely cause, getAttributionImage() was not updated in r36174/osm which it likely does need.

Last edited 2 months ago by sebastic (previous) (diff)

comment:9 by taylor.smock, 2 months ago

Cc:	GerdP added

I think this might be a regression from #23430.

follow-up: 12 comment:10 by taylor.smock, 2 months ago

@GerdP: In #23430, I think you were just interested in validator.selectionFilter.

Would

src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java

diff --git a/src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java b/src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java

-              a
     public void preferenceChanged(PreferenceChangeEvent e) {
         super.preferenceChanged(e);
         // see #23430: update selection so that filters are applied
+        DataSet ds = MainApplication.getLayerManager().getActiveDataSet();
+        if (ds != null) {
+            updateSelection(ds.getAllSelected());
+        if (ValidatorPrefHelper.PREF_FILTER_BY_SELECTION.equals(e.getKey())) {
+            DataSet ds = MainApplication.getLayerManager().getActiveDataSet();
+            if (ds != null) {
+                updateSelection(ds.getAllSelected());
+            }
+        }
+    }

work for you?

comment:11 by taylor.smock, 2 months ago

Milestone:	→ 24.02
Summary:	Hangs when downloading Bing imagery, but only the first time in a session → [PATCH] Hangs when downloading Bing imagery, but only the first time in a session

in reply to: 10 comment:12 by GerdP, 2 months ago

Replying to taylor.smock:

@GerdP: In #23430, I think you were just interested in validator.selectionFilter.

Would
src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java
diff --git a/src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java b/src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java
a b

743 743 public void preferenceChanged(PreferenceChangeEvent e) {

744 744 super.preferenceChanged(e);

745 745 // see #23430: update selection so that filters are applied

746 DataSet ds = MainApplication.getLayerManager().getActiveDataSet();

747 if (ds != null) {

748 updateSelection(ds.getAllSelected());

746 if (ValidatorPrefHelper.PREF_FILTER_BY_SELECTION.equals(e.getKey())) {

747 DataSet ds = MainApplication.getLayerManager().getActiveDataSet();

748 if (ds != null) {

749 updateSelection(ds.getAllSelected());

750 }

749 751 }

750 752 }

751 753
work for you?

Probably yes. How can this have an influence on the Bing layer?

comment:13 by taylor.smock, 2 months ago

The problem occurs when a preference change happens.
From comment:7, when we are first adding the Bing imagery layer, we have locked the MainLayerManager instance on the EDT (synchronized method). We then block on getting the attribution for Bing imagery in the EDT (this is not ideal; it would probably be better to just not load tiles until after the attribution is loaded, but it is what currently happens).
While we are blocking the EDT waiting on Bing attribution information, the thread getting the attribution information fetches the content and tries to cache it. The process of caching the attribution information currently depends upon writing a preference variable.
When we write a preference variable, we fire a preference changed event to preference change listeners, of which ValidatorDialog is one.
The ValidatorDialog then tries to get the active dataset via MainLayerManager#getActiveDataSet, which is a synchronized method. This blocks until the EDT releases the lock, which it won't, since it is waiting on the attribution to finish loading.

comment:14 by GerdP, 2 months ago

OK, thanks for the explanation. I can't test your patch now, but feel free to commit it when it prevents this lock. The problem in #23430 is very unlikely to happen and it existed for many years.

comment:15 by sebastic, 2 months ago

I've added the proposed patch to the Debian package, and it seems to fix the issue.

comment:16 by taylor.smock, 2 months ago

Resolution:	→ fixed
Status:	reopened → closed

In 19016/josm:

Fix #23540: When a Linux distribution removes the Bing png from JMapViewer, JOSM hangs when loading a Bing imagery layer

This is due to an interaction between JOSM preferences, the ValidatorDialog, and
the cached Bing imagery layer.

The specific interaction that leads to the freeze is as follows:

User starts process of adding a Bing imagery layer to JOSM
In the EDT we call a synchronized method in MainLayerManager
In the EDT we block on a separate thread that is fetching the Bing attribution data
In the separate thread, we attempt to set cache information in preferences
Setting the preference fires a preference change event
One of the listeners, specifically ValidatorDialog, then calls another synchronized method in MainLayerManager

Steps 2 and 6 are the problem points. This patch fixes that by only
attempting to perform the update by only listening to a specific preference,
instead of all of them.

The alternative to this patch uses Config#addKeyPreferenceChangeListener
instead. This was not done since ToggleDialog is already listening to all
preference changes.

Modify Ticket

Change Properties

Summary:
Type:		Priority:
Milestone:		Component:
Version:		Keywords:
Cc:	Set your email in Preferences

Action

leave as closed The owner will remain team.

change resolution as The resolution will be set.

reopen The resolution will be deleted. Next status will be 'reopened'.

Add Comment

Your email or username:

E-mail address and name can be saved in the Preferences .

You may use WikiFormatting here.

Attachments ↑ Description ↑

Note: See TracTickets for help on using tickets.

Download in other formats:

Context Navigation

#23540 closed defect (fixed)

[PATCH] Hangs when downloading Bing imagery, but only the first time in a session

Description

Attachments (2)

Change History (18)

follow-up: 3 comment:1 by achadwick, 2 months ago

comment:2 by achadwick, 2 months ago

in reply to: 1 comment:3 by sebastic, 2 months ago

comment:4 by achadwick, 2 months ago

comment:5 by GerdP, 2 months ago

by sebastic, 2 months ago

by sebastic, 2 months ago

comment:6 by sebastic, 2 months ago

follow-up: 8 comment:7 by taylor.smock, 2 months ago

in reply to: 7 comment:8 by sebastic, 2 months ago

comment:9 by taylor.smock, 2 months ago

follow-up: 12 comment:10 by taylor.smock, 2 months ago

src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java

comment:11 by taylor.smock, 2 months ago

in reply to: 10 comment:12 by GerdP, 2 months ago

src/org/openstreetmap/josm/gui/dialogs/ValidatorDialog.java

comment:13 by taylor.smock, 2 months ago

comment:14 by GerdP, 2 months ago

comment:15 by sebastic, 2 months ago

comment:16 by taylor.smock, 2 months ago

Modify Ticket

Add Comment

by anonymous

Download in other formats: