• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Multiple JVMs as a workaround

 
Ranch Hand
Posts: 919
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 9626
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
RMI has something called Object Activation. Might be an interesting solution.
 
Bartender
Posts: 1844
Eclipse IDE Ruby Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic