Following the discussion in https://github.com/OpenHistoricalMap/issues/issues/783#issuecomment-2213015033, CGImap should block runaway JOSM upload attempts, which could result from a very slow (or fairly contended) database along with repeated JOSM attempts to re-upload the same data over and over (+some connection timeout). As a result, multiple uploads might be piling up, which could cause undesirable effects like duplicate uploads or blocked server resources.
This issue does not occur in osm dev or production to my knowledge. The db is sufficiently fast in both cases.
Potential side effects of this change: clients which are sending diff upload and changeset close requests asynchronously without waiting for a server response might no longer work. Also, clients uploading smaller chunks for the same changeset in parallel will no longer work.
It's not clear, if there are any clients actually doing this. Even today, uploads for the same changeset id would be processed strictly sequentially (different changeset ids are of course processed in parallel).
Following the discussion in https://github.com/OpenHistoricalMap/issues/issues/783#issuecomment-2213015033, CGImap should block runaway JOSM upload attempts, which could result from a very slow (or fairly contended) database along with repeated JOSM attempts to re-upload the same data over and over (+some connection timeout). As a result, multiple uploads might be piling up, which could cause undesirable effects like duplicate uploads or blocked server resources.
Patch in https://github.com/mmd-osm/openstreetmap-cgimap/tree/patch/resi1 introduces a "NOWAIT" flag when locking the changesets table. In case the single row for a changeset id + user id cannot be locked, the upload is aborted immediately.
This issue does not occur in osm dev or production to my knowledge. The db is sufficiently fast in both cases.
Potential side effects of this change: clients which are sending diff upload and changeset close requests asynchronously without waiting for a server response might no longer work. Also, clients uploading smaller chunks for the same changeset in parallel will no longer work.
It's not clear, if there are any clients actually doing this. Even today, uploads for the same changeset id would be processed strictly sequentially (different changeset ids are of course processed in parallel).