Kepler

On Windows XP using a new test 2.3.0 installer, I've now seen this bug (failing to quit the current process when clicking the Apply and Restart button in the Module Manager GUI) occur from within Kepler. I.e. Kepler 2.3.0 failed to quit when switching to 2.2.0 using the MM GUI, leaving the user with an undisposed MM GUI, and two different versions of kepler up and running.

Changing title and promoting taget to 2.3.0.

I've done further testing trying to replicate one particular form of this bug on a p4 3ghz 1gb RAM WinXP box. When using the MM GUI from within Kepler 2.3.0, I see Kepler 2.3.0 and its MM GUI actually do eventually dispose, but it takes a very long time (~100s).

With 2.2.0 already downloaded, switching to it from within Kepler 2.3.0, it takes about 25seconds for 2.2.0 to completely start up. Then about 100 seconds later 2.3.0 and its associated MM GUI closes. I've run this test 3 or 4 times and get very similar times each test. While doing this I monitor the CPU w/ Windows Task Manager, and see that it is essentially idle during the 100second wait for 2.3.0 and its MM GUI to close.

Using the exact same test procedure on my mac, I'm unable to replicate -- 2.3.0 and its associated MM GUI close in a couple seconds, before the 2.2.0 splash comes up. Both XP and OS X are using java 1.6.0_26.

Side question: why are all the MM GUI classes that restart kepler calling System.exit(1)? These calls occur in areas where kepler is intentionally being quit without error, why not use exit(0)?

Unable to replicate this on the same XP box, when using MM GUI from within Kepler 2.2.0 to switch to Kepler 2.1.0 -- 2.2.0 and its MM GUI close very quickly.

Should be fixed at r28643. Will close once verified using a 2.3.0 from an installer on my Windows box.

The first process was hanging on HSQL.shutdownServers() server.shutdown() calls (normally the first, 9001, but sometimes the second, 9003). The issue seemed to be that the 2nd instance of kepler was mid-startup and interfering with the 1st closing properly. I.e. probably the first was trying to shut down the dbs when the 2nd was connecting or already connected.

It used to be the 2nd process was spawned before the 1st process notified its shutdown listeners (where db shutdowns occur). I changed this ordering to fix the problem.

Verified fixed on my XP box.

Original Bugzilla ID was 5484