Opened 6 years ago
Closed 6 years ago
#18243 closed defect (othersoftware)
Tiles do not load - Connection Refused
Reported by: | mcpicoli | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core imagery | Version: | tested |
Keywords: | network | Cc: |
Description (last modified by )
The problem: After using JOSM for a few minutes (many GPX layers, one data layer, one "Openstreetmap Carto" layer), the map layer stops loading tiles, and starts showing "Error downloading tiles: java.net.ConnectException: Connection refused: connect".
It usually "resets" to working status after several hours.
Before a few minutes of usage, everything is normal, everything loads and no errors are shown.
The console window is littered with hundreds (or thounsands) of java exceptions like this:
2019-10-21 11:38:58.775 INFO: GET https://b.tile.openstreetmap.org/18/97118/148792.png -> !!! 2019-10-21 11:38:58.775 WARNING: java.net.ConnectException: Connection refused: connect java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:673) at sun.net.NetworkClient.doConnect(NetworkClient.java:175) at sun.net.www.http.HttpClient.openServer(HttpClient.java:463) at sun.net.www.http.HttpClient.openServer(HttpClient.java:558) at sun.net.www.protocol.https.HttpsClient.<init>(HttpsClient.java:264) at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191) at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162) at org.openstreetmap.josm.tools.Http1Client.performConnection(Http1Client.java:77) at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:143) at org.openstreetmap.josm.tools.HttpClient.connect(HttpClient.java:123) at org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.loadObject(JCSCachedTileLoaderJob.java:322) at org.openstreetmap.josm.data.cache.JCSCachedTileLoaderJob.run(JCSCachedTileLoaderJob.java:231) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
If the imagery is in the cache, after a few seconds, the error message clears and the cached tiles are shown.
While I know it is almost surely a network or tileserver problem, it started very recently after I upgraded from 15238 (or maybe 13367?). Maybe something changed in the current version that somehow triggers something at the tileserver that blocks connections?
Download/upload of data layers do not suffer from these effects.
Thanks.
Using version 15390.
Attachments (1)
Change History (4)
by , 6 years ago
Attachment: | OSM Tiles not loaded.jpg added |
---|
comment:1 by , 6 years ago
Sorry, forgot to say:
- Windows 10, latest update as of 2019-10-21
- java -version reports:
java version "1.8.0_171" Java(TM) SE Runtime Environment (build 1.8.0_171-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
comment:2 by , 6 years ago
Description: | modified (diff) |
---|
comment:3 by , 6 years ago
Component: | Core → Core imagery |
---|---|
Keywords: | network added |
Resolution: | → othersoftware |
Status: | new → closed |
It's not a change from JOSM. Something changed either on your network connection, computer, or OSM server side. But as we didn't get other similar reports I tend to exclude a OSM server change too.
Sample image of the problem