Applets and shell scripts

Hi,
I have applets that run shell scripts from jsp pages on UNIX server. By communicating with Sun, they said that running shell scripts from applets is a BAD idea since there is no real control of the shell scripts from an applet. However, I must run these shell scripts. The problem that I am facing is that once shell script is ran, and there is a problem with it, it hangs and after sometime starts to suck all virtual memory from my JVM on the server. This causes the whole JVM to hang as well and crashes my web server and Apache. Interesting thing is that since there is only one JVM for the whole Java applcation, it takes every applet down. So, if there are 10 users logged in using applets and one of the users rans shell script that crashes the system all users are screwed and logged off the system. This behavior is unlike UNIX's wher if one process crashes only that process dies, but the rest are just fine.
I need a solution to safely run shell scripts from my applets and ensuring that if one applet crashes only one user dies and not the whole system.
Any suggestions?
thanks,
Alex

Are you running the shell scripts with Runtime.exec()? Do you run the shell script as a background process: Runtime.getRuntime().exec("script.sh &")? Running it in the background may help.
[ April 11, 2003: Message edited by: Michael Morris ]

There's some things that just don't jibe here. Applets don't run on the server, and if the applet does a Runtime.exec() - which requires a signed applet - the shell script likewise doesn't run on the server. It runs on the client. Clients don't share VMs, so this whole situation doesn't make sense.
A servlet could encounter this kind of problem, but I wouldn't count on being able to use the "&" option directly, since that's a feature of the command shell, and the item being executed isn't being launched from a command shell (though it could be a script that did launch that way).
I'm afraid that the only real solution is to stop trying to hack around the problem. Cleaning up the shell scripts so that an abnormal termination is caught and handled cleanly would help (as would fixing the apps the script isinvoking so they won't die to begin with). However, you'd still see a degredation in system response as the number of users increased.
Most of the time a better response is to setup a backend server that runs asynchronous to the web process. The user dumps in a request and the backend server schedules, then processes it, posting a status and/or sending a completion message to let the user know when it's done. If the action will never exceed about 1-3 minutes, you could spin off a thread and exec() the work, but even there you really need clean scripts.