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
