Multiple JVMs as a workaround

[George Brown]

I am considering a workaround to a problem in an existing system. The system relies upon a C++ shared library, written by the customer and loaded by my JVM using System.loadLibrary(). Unfortunately the library intermittently blows up, taking the entire JVM with it.
The customer, unfortunately, can't be trusted to reliably fix their own library, so I need to find a way of dealing with the library's faults until the library code can be fixed.
I am considering spawning a second JVM from the first using Runtime.exec(), with the second JVM loading the dodgy library, and accepting requests through either a socket or RMI, and returning the results the same way. That way when the library blows up the first JVM isn't taken down with it, and the spawner can re-spawn the second JVM when it realises that it has disappeared.
It's a desparate situation requiring desperate measures, but something needs to be done. Can anyone suggest a better alternative?

[Michael Morris]

That sounds like as good a solution as I can think of. You might even consider pooling JVMs and using a manager running on a seperate thread that could detect when one went down and spawn new JVMs as required. Since it is pure Java, RMI would probably be your best bet but there will be some performance overhead involved.

[Ernest Friedman-Hill]

Offtopic rambling, sorry:
A long time ago, I was new on a project and I had to do a demo for a big client. I was coming in to help with a C language codebase that had absolutely gotten out of hand. The app crashed constantly. What I did for the demo was launch the app from a script which restarted the app when it exited with a flag to tell it to throw up a dialog box saying something innocuous like "Settings have been reloaded." The effect was that you'd be working and then this dialog box would come up, you could dismiss it and go back to work. The demo went fine -- even though the app crashed twice, nobody realized it.
Over the next three months we replaced every single line of the original codebase.

[Joe Ess]

RMI has something called Object Activation. Might be an interesting solution.

[Joel McNary]

Originally posted by Ernest Friedman-Hill:
Offtopic rambling, sorry:
A long time ago, I was new on a project and I had to do a demo for a big client. I was coming in to help with a C language codebase that had absolutely gotten out of hand. The app crashed constantly. What I did for the demo was launch the app from a script which restarted the app when it exited with a flag to tell it to throw up a dialog box saying something innocuous like "Settings have been reloaded." The effect was that you'd be working and then this dialog box would come up, you could dismiss it and go back to work. The demo went fine -- even though the app crashed twice, nobody realized it.
Over the next three months we replaced every single line of the original codebase.

Sounds quite funny. Recently we did a demonstration of a rich-client player (similar to Flash) to a large company in Chicago. Unfortunately, the pragram was an alpha version, and it would crash whenever you changed screens without restarting the application between.
The solution? Two computers, one projector. One computer would demonstrate the application one screen at a time. When the demo for that screen was over, the other computer would take over the projector for the power-point presentation. During that time, the application would be shut down and restarted and the next screen brought up in time for it to be demonstrated using the projector.
The (potential) client was very impressed and none the wiser.