frozen editor while panning or zooming of the map

[Michael Zangl]

Hi,

No, getResponseCode() is not only for logging. It just happens to be the 
first method that is called on the HTTP result and triggers the Thread 
to wait for the HTTP response (therefore the long wait). Since we need 
the response any way, it won't be a noticeable performance improvement 
to wrap that block in an if statement.

Tile loading should be in background. You can completely ignore those 
loader threads and need to focus on the AWT Event Thread instead. This 
is the thread that should not be blocked. It can be blocked by several 
things, e.g.:
* Synchronisation (waiting e.g. for a tile thread)
* Graphics rendering (filters / ...)
* Stop-the-world garbage collection
* ...

All the things you *should* not see but something happened in your case 
that triggered one of those many possible events.

Since your freeze are multiple seconds, they might be long enough for 
you to trigger a stack trace. For this, you need a tool that generates 
such strack traces (e.g. VisualVM) connected to JOSM and ready to do a 
stack trache just by klicking one button (open the correct tab, put the 
window next to JOSM). Once JOSM freezes, quickly trigger that button. If 
you are fast enough, you get the exact spot where JOSM spends it's time.

Michael

On 10.09.2018 01:11, Stephan Knauss wrote:
> Hello,
> 
> I sometimes suffer delays of 10-15s when panning or zooming the map.
> 
> I had the impression it started to become worse when tile serving was 
> switched over to https, but switching back to http did not fully fix it.
> With JOSM being updated in parallel all not that great to track down 
> such issues. Just seeing in the terminal window large gaps between tile 
> requests. Hiding imagery tiles always makes it fast. So it is certainly 
> related.
> 
> So today I tried again to reproduce it, this time with YourKit Profiler 
> connected.
> 
> I noticed some shorter delays, but couldn't fully reproduce the extreme 
> delays.
> 
> Majority of time (about 60%) was spent in what I guess is tile loading:
> HttpClient.java:91 
> org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)
> 
> I have typically the two DG layers active sometimes also esri and bing 
> to compare the images and alignment. With my large screen having 4k 
> resolution, I might have a significant larger window visible than the 
> average user.
> I sometimes feared that mapbox might throttle the tile delivery. My 
> connection itself is a fast 50 MBit link which typically is fast towards 
> mapbox.
> 
> I then thought to make it a bit harder for JOSM and reduced the maximum 
> connections per host down from 12 connections to 6 connections.
> 
> I got multiple seconds of frozen map now. After panning or zooming the 
> view is frozen. Mouse still moves, but the line I am currently painting 
> no longer follows the cursor. Just jumps back after five to ten seconds.
> 
> Now the majority of time is spent here:
> 
> HostLimitQueue.java:30 
> org.openstreetmap.josm.data.cache.HostLimitQueue.poll(long, TimeUnit)
> 
> Can you please give some high-level explanation on how the GUI is 
> connected to tile loading?
> 
> My expectation would be that tile loading happens in the background. In 
> case of a blocked download (for whatever reason) my expectation would be 
> that just the background tiles are not updated. panning, zooming or 
> editing should not wait on it.
> Is there a critical section somewhere which would be better not shared 
> between the editor and tile loading?
> 
> How much personal details is recorded in the profiler snapshots? Would 
> it help if I share one? Anyone more experienced interested in running a 
> profiling session via skype?
> 
> 
> If I read the call tree correctly, then below:
> HttpClient.java:91 
> org.openstreetmap.josm.tools.HttpClient.connect(ProgressMonitor)
> the routines
> HttpClient.java:149 <...> 
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode()
> and
> HttpClient.java:149 <...> java.net.HttpURLConnection.getResponseCode()
> 
> use 40% of the time there. Do I get it right that this is only used for 
> logging? Maybe only do this then in case log-level is at least info
> 
> ### Eclipse Workspace Patch 1.0
> #P JOSM
> Index: src/org/openstreetmap/josm/tools/HttpClient.java
> ===================================================================
> --- src/org/openstreetmap/josm/tools/HttpClient.java    (revision 14108)
> +++ src/org/openstreetmap/josm/tools/HttpClient.java    (working copy)
> @@ -144,13 +144,15 @@
>               try {
>                   connection.connect();
>                   final boolean hasReason = reasonForRequest != null && 
> !reasonForRequest.isEmpty();
> -                Logging.info("{0} {1}{2} -> {3}{4}",
> -                        requestMethod, url, hasReason ? (" (" + 
> reasonForRequest + ')') : "",
> -                        connection.getResponseCode(),
> -                        connection.getContentLengthLong() > 0
> -                                ? (" (" + 
> Utils.getSizeString(connection.getContentLengthLong(), 
> Locale.getDefault()) + ')')
> -                                : ""
> -                );
> +                if (Logging.isLoggingEnabled(Logging.LEVEL_INFO)) {
> +                    Logging.info("{0} {1}{2} -> {3}{4}",
> +                            requestMethod, url, hasReason ? (" (" + 
> reasonForRequest + ')') : "",
> +                            connection.getResponseCode(),
> +                            connection.getContentLengthLong() > 0
> +                                    ? (" (" + 
> Utils.getSizeString(connection.getContentLengthLong(), 
> Locale.getDefault()) + ')')
> +                                    : ""
> +                    );
> +                }
>                   if (Logging.isDebugEnabled()) {
>                       Logging.debug("RESPONSE: {0}", 
> connection.getHeaderFields());
>                   }
> 
> 
> 
> Stephan
> 
>