Opened 3 years ago
Closed 8 months ago
#21570 closed defect (worksforme)
Open changesets don't show up in the upload dialog
Reported by: | gaben | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core Webstart | Version: | |
Keywords: | template_report open changeset java8 jnlp | Cc: |
Description (last modified by )
What steps will reproduce the problem?
- Use JOSM JNLP distribution (WebStart)
- Make some changes, upload and don't close the changeset
- Make changes again
- Try to upload to the same, still open changeset
- Click on the changeset refresh button
What is the expected result?
The changeset created in step 2 shows up in the upload dialog changeset list, upload to the same changeset possible. The changeset refresh button works.
What happens instead?
Sometimes the changeset doesn't show up, as if it would be closed. Clicking on the changeset refresh button results in a dialog, saying "No open changesets" or similar.
Please provide any additional information below. Attach a screenshot if possible.
After JOSM restart, the open changesets always show up in the changeset list.
It's a long-standing issue and #19780 may be related.
In Postman, the OSM API returns the expected result (at least one open changeset) in reasonable time (no timeout or server error).
URL:https://josm.openstreetmap.de/svn/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2021-11-12 11:23:59 +0100 (Fri, 12 Nov 2021) Build-Date:2021-11-13 02:31:03 Revision:18323 Relative:URL: ^/trunk Identification: JOSM/1.5 (18323 hu) Windows 10 64-Bit OS Build number: Windows 10 Pro for Workstations 2009 (19043) Memory Usage: 2390 MB / 7266 MB (1279 MB allocated, but free) Java version: 1.8.0_311-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel Screen: \Display0 1920×1200 (scaling 1.00×1.00) Maximum Screen Size: 1920×1200 Best cursor sizes: 16×16→32×32, 32×32→32×32 System property file.encoding: Cp1250 System property sun.jnu.encoding: Cp1250 Locale info: hu_HU Numbers with default locale: 1234567890 -> 1234567890 VM arguments: [-Djava.security.manager, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm-latest.jnlp, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlp.tk=awt, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.splashport=54425, -Djnlpx.home=<java.home>\bin, -Djnlpx.remove=false, -Djnlpx.offline=false, -Djnlpx.relaunch=true, -Djnlpx.session.data=%UserProfile%\AppData\Local\Temp\session524324530548763547, -Djnlpx.heapsize=NULL,NULL, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\31\583aa85f-4236f0ee] Dataset consistency test: No problems found
Attachments (0)
Change History (18)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
comment:3 by , 3 years ago
Description: | modified (diff) |
---|
Before writing the ticket I checked the OSM API and it returns the expected result, so it's a JOSM thing.
Updated the ticket according to this.
comment:5 by , 3 years ago
Today I tried editing while running the debugger in the background, but it just works fine. Although yesterday popped up randomly again. I need to map with a debugger, I guess :(
comment:6 by , 3 years ago
I ran into the issue again but forgot the debugger. This time at least I have a screen record, just in case :)
I think it's something to do with changeset caching. JOSM was running a few hours idle in the background.
comment:7 by , 3 years ago
I'm getting closer to reproduction. This time forgot to add an entrance, tried uploading seconds after the first upload and the changeset already not showing up in the list. JOSM is running idle for hours in the background.
comment:8 by , 3 years ago
Now I lost path. After restart, open changesets still show up, but clicking on the refresh button says there isn't any, so JOSM settles in an impossible state.
This time by restart I mean restart from the file menu. AFAIK it means the JVM not shutting down, so maybe it is a #javabug? Of course I forgot the debugger again...
comment:9 by , 3 years ago
Component: | Core → Core Webstart |
---|
I suspect it's webstart related issue because when I'm running JOSM jar from IDE with a debugger it never occurs.
comment:10 by , 3 years ago
Is this only related to the upload dialog? Can you take a look at the changeset manager and if all CSs are listed there if you request your changesets.
comment:11 by , 3 years ago
Interesting. When I refresh changesets from the upload dialog, the changeset list not updating. But when I download my changesets (all, not only open ones) within the changeset manager, the upload dialog gets refreshed and the open ones show up.
comment:12 by , 3 years ago
This could be an intermittent server side issue. What happens if you keep hitting the refresh changeset button (after a reasonable delay)? Does it always fail?
comment:13 by , 3 years ago
I see that ChangesetManagementPanel
uses DownloadOpenChangesetsTask
but ChangesetCacheManager
uses ChangesetQueryTask
for virtually the same thing.
Besides the useless code duplication DownloadOpenChangesetsTask
does some funny things with user authentication. So it may be an issue with user auth too. Are you using Oauth or basic authentication (in Preferences|OSM Server)?
comment:14 by , 3 years ago
Description: | modified (diff) |
---|
I tried that in the past. The refresh button does nothing even after a minute or two, unfortunately. Also, the server is available and returns the expected data when occurs, verified multiple times in Postman.
Yeah, the code duplication doesn't help either. I tried debugging the relevant code, but when launched with .jar it never occurred. It has something to do with WebStart. I'm using OAuth.
Updated the possible reproduction steps.
comment:15 by , 3 years ago
Also, the refresh button doesn't generate network traffic when the issue occurs, checked in Wireshark.
comment:17 by , 18 months ago
Up, the issue still persists, dealing with it every day.
A workaround is to open the Changeset Manager and then click on the "My changesets" button.
comment:18 by , 8 months ago
Keywords: | java8 jnlp added |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
After JOSM requires Java 11 or up, this should no longer be an issue, as in my testing it only affected JOSM with Java 8 JNLP distribution.
(Just to be clear, I'm running Java 21 now with JNLP and no longer see the reported behaviour.)
The changeset reload button depends on network availability. See if the API server is good. Also, changesets timeout on the server all by themselves.