JOSM freezing up for a few seconds when doing anything

[Colbertson]

What steps will reproduce the problem?

Dunno, seems to happen almost at random
Will try update ticket with more info if it happens again

What is the expected result?

It not doing that

What happens instead?

Whenever selecting an object, trying to upload/download data or doing basically anything else JOSM freezes for a few seconds before the action happens

Please provide any additional information below. Attach a screenshot if possible.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2024-02-05 12:56:34 +0100 (Mon, 05 Feb 2024)
Revision:18969
Build-Date:2024-02-06 02:30:58
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18969 en) Linux Freedesktop SDK 23.08 (Flatpak runtime)
Memory Usage: 312 MB / 1970 MB (88 MB allocated, but free)
Java version: 17.0.9+7, Flathub, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: XFCE
VM arguments: [--module-path=/app/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]

Plugins:
+ Mapillary (2.2.0)
+ MicrosoftStreetside (36200)
+ SimplifyArea (36209)
+ apache-commons (36176)
+ apache-http (36176)
+ buildings_tools (36226)
+ ejml (36176)
+ geotools (36176)
+ gridify (1606242219)
+ jackson (36176)
+ javafx (36200)
+ jaxb (36118)
+ jna (36176)
+ jts (36004)
+ merge-overlap (36178)
+ opendata (36200)
+ reverter (36226)
+ shrinkwrap (v1.0.4)
+ terracer (36205)
+ undelete (36226)
+ utilsplugin2 (36226)
+ waydownloader (36196)
+ wikipedia (605)

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Bench&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_buildings_en&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/AdvertisingStyle&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/FixmeAndNote&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/IncompleteObjectWarnings&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/ParcelLocker&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Modified&zip=1

[taylor.smock]

Identification: JOSM/1.5 (18969 en) Linux Freedesktop SDK 23.08 (Flatpak runtime)

This makes life a bit trickier. The Java SDK doesn't (currently) include jstack. I'll see if I can get that changed.

[taylor.smock]

It looks like the default install.sh script for the JDK used by the flatpak JOSM doesn't include any useful debug tools.

If you are on a distro where it is easy to install the full JDK, can you please do so?

The commands you'll want to run are jps (which will give a printout of the running Java processes) and jstack, which takes the process id from jps to get the thread dump from.

Example:

$ jps
42305 Jps
41159 Launcher
94393 Main
41160 MainApplication
95310 SonarLintServerCli
$ jstack 41160
[...stack trace here...]

A oneliner that will work if MainApplication is the name shown under jps is jstack $(jps | grep 'MainApplication' | awk '{print $1}').

[taylor.smock]

#23559 may be a duplicate.

Plugins in common (but not common versions):

• Mapillary
• SimplifyArea
• apache-commons
• apache-http
• buildings_tools
• ejml
• geotools
• gridify
• jackson
• jaxb
• jna
• jts
• opendata
• shrinkwrap
• utilsplugin2

Side note: I'm suspecting the problem is shrinkwrap (it is a plugin I haven't heard of before). You can try disabling it to see if that fixes the problem.

[taylor.smock]

Ticket #23559 has been marked as a duplicate of this ticket.

[taylor.smock]

It looks like it is a problem with shrinkwrap. I just loaded a large area (​https://www.openstreetmap.org/relation/1411341) into JOSM and clicked on a node. It took quite some time for JOSM to become responsive again.

[taylor.smock]

@Ubipo: The problem appears to be that you are using getBaseData to enable/disable your actions.

Most of the time spent is in initializing the LinkedHashSets and iterating through them to check and see if there are usable nodes and ways.

I would recommend replacing that function call in updateEnabledState with something like the following for the BalloonAction

        private fun hasUsableData(ds: DataSet?): Boolean {
            if (ds == null || ds.isLocked) {
                return false
            }
            return ds.nodes.stream().filter(Node::isUsable).limit(3).count() >= 3 &&
                    ds.ways.stream().filter(Way::isUsable).findAny().isPresent
        }

Why would that function be faster than the current function?

1. It isn't copying nodes and ways to another list (this also helps avoid some GC pressure)
2. We don't have to test every node and way in the dataset. In your code for getBaseData, it looks like you only care that there are at least 3 usable nodes and at least 1 usable way.

For the ShrinkWrapAction, I would recommend replacing getBaseData in updateEnabledState with something like

        private fun hasUsableData(ds: DataSet?): Boolean {
            if (ds == null || ds.isLocked) {
                return false
            }
            return ds.selectedNodes.stream().filter(Node::isUsable).limit(3).count() >= 3 &&
                    ds.ways.stream().filter(Way::isUsable).findAny().isPresent
        }

Side note: You might want to check the if statement right before throw BadBaseDataException("\"$ACTION_NAME\" requires at least one way on the active layer") in ShrinkWrapAction#getBaseData; I suspect you wanted to do if (usableWays.size < 1) instead of if (selectedNodes.size < 1).

[taylor.smock]

PR opened: ​https://github.com/ubipo/shrinkwrap/pull/5

[anonymous]

Fixed in v1.0.6 of the Shrinkwrap plugin: ​https://github.com/ubipo/shrinkwrap/pull/5#issuecomment-2016688561