Modify

Opened 3 months ago

Closed 2 months ago

Last modified 2 months ago

#22363 closed defect (fixed)

No UPload after OsmApiException: ResponseCode=400, Error Header=... too many nodes

Reported by: MichaelFS Owned by: taylor.smock
Priority: normal Milestone:
Component: Plugin continuosDownload Version:
Keywords: template_report Cc:

Description (last modified by MichaelFS)

What steps will reproduce the problem?

  1. Start JOSM with a certain node
  2. Zoom out until the scale in the upper left area shows 500 m
  3. Zoom out once again, the scale in the upper left area shows 1.000 m and two messages are shown: The old one, OSM-Server "api.openstreetmap.org" reports a bad request: Area too large, and a new one "Disabling continuous download until you zoom in.
  4. Zoom back to 500 m and apply any modification. Upload this - the uploads starts but will never finish. If you try the upload again, it says there is an upload aleady in progress.

What is the expected result?

Upload should be possible as usual.

The behaviour is absolutely the same with JOSM 18463.

Revision:18499
Is-Local-Build:true
Build-Date:2022-06-23 13:37:16

Identification: JOSM/1.5 (18499 SVN de) Linux Manjaro Linux
Memory Usage: 1248 MB / 7832 MB (444 MB allocated, but free)
Java version: 18.0.2+9, N/A, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.nimbus.NimbusLookAndFeel
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: de_DE.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: de_DE
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: KDE
VM arguments: [-Dawt.useSystemAAFontSettings=gasp]
Program arguments: [--debug]
Dataset consistency test: No problems found

Plugins:
+ buildings_tools (36011)
+ continuosDownload (101)
+ fieldpapers (v0.5.0)
+ reverter (36011)
+ terracer (35978)
+ undelete (36011)
+ utilsplugin2 (36011)

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/AddressValidator&zip=1

Last errors/warnings:
- 01001.769 E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm>
- 01001.784 E: Fehlerhafte Anfrage - <html>Der OSM-Server »api.openstreetmap.org« meldete eine fehlerhafte Anfrage.<br><br>Das angeforderte Gebiet ist zu groß oder enthält zu viele Daten.<br>Versuchen Sie, ein kleineres Gebiet herunterzuladen oder nutzen Sie einen Datenbankexport.</html>
- 01001.811 E: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<You requested too many nodes (limit is 50000). Either request a smaller area, or use planet.osm>
- 01001.820 E: Fehlerhafte Anfrage - <html>Der OSM-Server »api.openstreetmap.org« meldete eine fehlerhafte Anfrage.<br><br>Das angeforderte Gebiet ist zu groß oder enthält zu viele Daten.<br>Versuchen Sie, ein kleineres Gebiet herunterzuladen oder nutzen Sie einen Datenbankexport.</html>

Attachments (0)

Change History (12)

comment:1 Changed 3 months ago by MichaelFS

Description: modified (diff)

comment:2 Changed 3 months ago by skyper

Component: CorePlugin continuosDownload

Sounds like a problem of continuosDownload plugin.

comment:3 in reply to:  2 Changed 3 months ago by MichaelFS

Replying to skyper:

Sounds like a problem of continuosDownload plugin.

May be, here is what I checked:

  • Started JOSM/1.5 (18499 SVN de) Linux Manjaro Linux
  • DEactivated continuosDownload
  • Downloaded an area manually with scale 50 m and modified a node there
  • Increased the are to 1.000 m
  • "Download in actual view", Server says somethin like "ResponseCode=400, Error Header=<You requested too many nodes"
  • Started the UPload, the UPload works fine.

But: I did the steps described in the OT over weeks in the past and the issue is new since about several days. Haver there been any changes, which can produce the issue?

comment:4 Changed 2 months ago by taylor.smock

Owner: changed from team to MichaelFS
Status: newneedinfo

I did make an update to the continuousDownload plugin a few weeks ago (see wiki:PluginsSource?action=diff&version=740 ).
I've been able to reproduce, with the caveat that it was short lived.

I suspect but have not verified that the worker thread is blocked waiting for data to finish downloading. The problem isn't necessarily that the download did not work, but more of an issue that there is a queue of downloads blocking the worker thread.

If this happens again, and does not clear up by itself after 30 seconds or so, can you get a thread dump?

EDIT: Nevermind. It looks like the worker thread is stuck waiting on future.get() in PostDownloadHandler.

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

comment:5 Changed 2 months ago by taylor.smock

Owner: changed from MichaelFS to taylor.smock
Status: needinfoassigned

This is a PITA. It appears that the executor isn't setting the state correctly, or something, which means that future.get() is never completing exceptionally.

I've got a test, now I just have to figure out the appropriate fix.

comment:6 Changed 2 months ago by MichaelFS

Thank you for checking and your work on a solution. It happens here every time, I zoom to a scla eof 500 m ore more. That is whenn a message is shown: "Disabling continuoous download until ... "
This message is new and the misbehaviour was first seen exactly that day, when the "disabling ..."-message was shown first time. Furthermor continuous download is not enabled after zooming in f.e. to scale 100 m.

comment:7 Changed 2 months ago by taylor.smock

I've got a fix for both. I'll do a release today.

comment:8 in reply to:  7 ; Changed 2 months ago by MichaelFS

Thank you @ taylor.smock

I've got a fix for both. I'll do a release today.

Great! Actually I'm running 22160 manually (because of solved issue #22160) as MANJARO still has 18463. Please let me know the new ID and download, I'll try it soon ...

comment:9 in reply to:  8 ; Changed 2 months ago by taylor.smock

Resolution: fixed
Status: assignedclosed

Replying to MichaelFS:

Great! Actually I'm running 22160 manually (because of solved issue #22160) as MANJARO still has 18463. Please let me know the new ID and download, I'll try it soon ...

Side note: you can use josm-tested.jar instead of what I put in #22160. Which I just deleted so that people don't download an old version.

I just got the i18n tarball so I can update the i18n before I do a release. So it should be available in the next 1-2 hours.

comment:10 Changed 2 months ago by taylor.smock

OK. It should be available on the update site in the next 10 minutes.

comment:11 in reply to:  9 Changed 2 months ago by MichaelFS

Replying to taylor.smock:

Side note: you can use josm-tested.jar instead of what I put in #22160. Which I just deleted so that people don't download an old version.

Sorry, I'm confused: I Downloaded josm-tested.jar but this shows as

Last:Changed Date: 2022-08-29 16:59:00 +0200 (Mon, 29 Aug 2022)
Revision:18543
Build-Date:2022-08-30 01:30:57
URL:https://josm.openstreetmap.de/svn/trunk

This is not including the new patch?

comment:12 Changed 2 months ago by taylor.smock

Did you read comment:81:ticket:22160? The patch was applied in r18532, and r18543 > r18532, so r18543 has the patch. I may have made some modifications to the shown revision for the build I uploaded for #22160 to make debugging easier, if the OSM server admins experienced a bunch of duplicate requests.

I do know that there was a recent issue with the OSM API (see https://github.com/openstreetmap/operations/issues/754 ).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain taylor.smock.
as The resolution will be set.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.