[patch] multiple JOSM instances: Bogus crash recovery attempt

[bastiK]

• have one JOSM session open, do something else and then open another instance of JOSM

=> JOSM thinks it crashed and tries to recover the file that is still open in the first instance.

[Don-vip]

This must have fixed fixed in the last 2 years as the problem does not occur with latest.

[rickmastfan67]

This isn't fixed. I was just able to duplicate it in r5475 after waiting about 5 or so minutes before opening a 2nd instance of JOSM.

[Don-vip]

Here's a patch tested on Windows, can someone try on other systems ?

The idea is to associate to each saved layer the PID of the JOSM instance that created it. Then, the new instance checks if the PID is still a running JVM (these hsperfdata files are created by HotSpot since java 1.4 and disappear when the JVM dies, for a normal stop or a crash).

[bastiK]

doesn't compile with java 6

[Don-vip]

You're sure ? I'm compiling in Java 6 and didn't use any private API. What's your error message ?

[bastiK]

    [javac] /home/te/prog/josm-hist/core/src/org/openstreetmap/josm/data/AutosaveTask.java:284: cannot find symbol
    [javac] symbol  : method listFiles(org.openstreetmap.josm.actions.ExtensionFileFilter)
    [javac] location: class java.io.File
    [javac]         File[] files = autosaveDir.listFiles(OsmImporter.FILE_FILTER);
    [javac]                                   ^

It expects java.io.FileFilter but gets javax.swing.filechooser.FileFilter.

[Don-vip]

Oh, my fault, I forgot to send a file. I let our ExtensionFileFilter implement java.io.FileFilter too as they have in common the same acceptFile() method.

[Don-vip]

FYI I tried to use JMX to check at runtime that the PID references a running JOSM instance and not just a Java application but encountered a lot of difficulties:

• there's a simple Attach API that allows to attach to a local JVM without any configuration for it, but it's only present in JDK, not in JRE
• as this API is lightweight (7 files only), I tried to include it into JOSM, but in fact, the API depends on larger native libraries (at least attach.dll on Windows) so I forgot it
• I didn't find how to attach a local JVM without using this API

So I thought of this hsperfdata method. I only checks for file presence as I don't know if we can really "use" it (it seems to be a sort of memory mapping file used for jvmstat but the file is not readable, even File.exists() fails, and it's not documented)

If you have alternative ideas I'm listening :)

[bastiK]

Works on Ubuntu Linux. I'd say it is a difficult problem and your approach solves it. If anyone has a better idea, we can still improve it.

My only concern is, when the JVM crashes big time, it might leave those temporary files behind. This is indeed the case, when I send a KILL signal to the java process. After starting a new instance of JOSM, it is cleaned up however (the old hsperfdata file is gone, a new one created). So all in all it seems to work.

[Don-vip]

Replying to bastiK:

My only concern is, when the JVM crashes big time, it might leave those temporary files behind. This is indeed the case, when I send a KILL signal to the java process. After starting a new instance of JOSM, it is cleaned up however (the old hsperfdata file is gone, a new one created). So all in all it seems to work.

OK we need then to do this test on more systems to be sure :)

[skyper]

Replying to Don-vip:

Replying to bastiK:

My only concern is, when the JVM crashes big time, it might leave those temporary files behind. This is indeed the case, when I send a KILL signal to the java process. After starting a new instance of JOSM, it is cleaned up however (the old hsperfdata file is gone, a new one created). So all in all it seems to work.

OK we need then to do this test on more systems to be sure :)

Is it possible to make a built .jar available ? Thanks.

[Don-vip]

Replying to skyper:

Is it possible to make a built .jar available ? Thanks.

Sure, here it is: ​http://www.sendspace.com/file/o97zad

[stoecker]

Status of this?

[skyper]

Did not get to test much (only different Linux i386 and amd64) but so far it always worked without problems where latest did show this bug.

[bastiK]

I've tested the patch on Windows XP and it works well. After killing the process with taskkill /pid ... /f, the file in the hsperfdata_user folder vanished (this is good).

So in my opinion there is no reason to hold back this patch any longer.

[Don-vip]

In 5566/josm:

fix #5288 - multiple JOSM instances: Bogus crash recovery attempt