Where I work they use the AppletContext.showDocument(URL) method when a user logs off our application, which is an applet, providing the desired logoff JSP. But they also have code that says if for some reason they are unable to get an AppletContext to simply call the Applet.destroy() method.
We are using a thin client architecture which means that we essentially have a bunch of dumb terminals connected to a server. I mention this because we will often have dozens if not 100's of instances of JVMs running - one for each applet.
Inside the destroy() method they dispose of all resources they acquired and then get a reference to Runtime and call runFinalization() and gc() - but it does not do a System.exit() or equivalent.
Questions
I understand that frees up resources and leaves you on the same web page but what does it do to the JVM that was running the applet?
If I add a call to System.exit() at the end of the destroy() what will it do to the other JVMs that are running on the thin client server?
For context, this is all necessary because while a page is active browsers (or the Java plugin, or both) hang on to your applet instance. Even if you remove it from the DOM or try other tricks to release that memory, until you navigate to a different page your applet instance is retained so you need to fully clean up in destroy(). I've done memory profiling which shows it's referenced in native code somewhere.
To answer your questions:
This depends on your version of Java. As of Java 6 update 10 (with the next-gen plugin) after a period of time with no applets running Java will shut itself down. This timeout has appeared to get shorter as the JVM startup time has decreased in the last year or two.
I don't believe applets (even signed ones) are allowed to call System.exit(). If it was allowed though, on modern browsers it would kill the instance of the JVM for that browser, none of the others. In the past it would've been likely to shut the entire browser down :)
EDIT:
Actually there's more to the story of Answer 1... that's true everywhere except OS X, where the next-gen plugin wasn't the default until somewhere around 6u27 (On 10.6 it was Java for OS X update 5, and 10.7 from day 1).
Related
I'm having trouble with a Jetty 9 server application that seems to go into some kind of resting state after a longer period of idleness. Normally the memory usage of the Java process is ~500 MB, but after being idle for some time it seems to drop down to less than 50MB. The first request that comes takes up to several seconds to respond whereas requests are normally on the scale of tens of milliseconds. But after one or two requests it seems like the application is back to it's normal responsive state.
I'm running on the 32-bit Oracle Java 8 JVM. My JVM configuration is very basic:
java -server -jar start.jar
I was hoping that this issue might be solvable through JVM configuration. Does anyone know if there's any particular parameter to disable this type of behavior?
edit: Based on the comment from Ivan, I was able to identify the source of the issue. Turns out Windows was swapping parts of the Java process out to disk. See my own answer below for a description of my solution.
Based on the comment from Ivan, I was able to identify the source of the issue. Turns out Windows was swapping parts of the Java process out to disk. This was clearly visible when comparing the private working set to the commit size in the task manager.
My solution to this was two-fold. First, I made a simple scheduled job inside my server app that runs every minute and does a simple test run to make sure that the important services never go inactive for long periods. I'm hoping this should ensure that Windows doesn't regard the related pages as inactive.
Afterwards, I also noticed that the process was executing with "Below normal" priority. So I changed the script that starts the server to ensure that it's running with "High" priority going forward. This seems likely to affect swapping behavior and may very well also have been enough to resolve the issue on it's own, but I only found it after already deploying my first solution so that remains unclear. In any case, everything seems to be working as it should now.
I have a Windows MFC application that:
(1) Loads the JVM (JNI_CreateJavaVM())
(2) Attaches the main thread to the JVM (AttachCurrentThread())
(3) Loads some Java classes and methods (FindClass() and GetMethodID() / GetStaticMethodID())
(4) Registers some native callbacks for use by Java code (RegisterNatives())
(5) Detaches the thread from JVM (DetachCurrentThread())
(6) Destroys the JVM (DestroyJavaVM())
All of the above functions succeed every other time I run the application. I know they succeed, because, additionally to the above, I interact with the application and successfully call Java static methods, and these Java methods successfully call my native callbacks. My application exits gracefully, and it is certain that the expected Java functions, and native callbacks, have been executed.
However, every other time that I run the application, the call to JNI_CreateJavaVM() fails (not populating the JavaVM *). Absolutely nothing changes between runs of the application. I simply run it once (successfully, even without doing anything except the above 6 steps), quit gracefully, run again, and it fails, back and forth. There are no exceptions to the back-and-forth success/failure - I can run it dozens of times, and it oscillates precisely every other time between success, and failing on the JNI_CreateJavaVM() line.
If necessary, I will paste more code. However, I hope somebody has an insight with what I've provided. (Note: this is a BCGSoft MFC property-sheet application, though I strongly doubt that matters.)
It looks like you are running into this bug (restated here) that is probably never going to be fixed.
Despite its name, DestroyJavaVM() does not actually destroy the JVM. What it does is signal the JVM that it should shut down, but the JVM actually waits until all the threads other than the Main thread have stopped before it actually shuts down. In fact, even then it does not fully clean up after itself, as the documentation states (quite cryptically): "The JDK/JRE still does not support VM unloading, however."
Also, I'm concerned about your step 2, "Attaches the main thread to the JVM". You do not need to attach the thread that created the JVM to the JVM and you may not detach that thread. If you really are doing that, then it's possible that is what is messing up your system. (The thread that creates the JVM is the JVM's "Main" thread. You only need to attach/detach other native threads to the JVM if they need access to it.)
By the way, JNI_CreateJavaVM() returns 0 on success, and you say it returns 0 the "failed" times, so in what sense is it failing? Which JVM (version, vendor) are you using?
I have been developing a Java application using J2EE and a Derby database. My boss does most of the testing and I do most of the coding, but he has come to me with a strange problem. He claims that occasionally the Java application "crashes his computer".
To mention a few details, first let me say that I am currently working remotely, so I can't be around when these "crashes" happen. Second, I use OS X 10.6 and he uses Windows XP (SP3 I believe). The Java application in question does not use any JNI or anything weird except for an embedded Derby database. Lastly, he said it freezes everything in Windows (his mouse doesn't even move) -- it doesn't show up in the console like an uncaught exception would.
So, is it possible that my Java program is crashing his computer? I didn't think that Java code could have any system-wide effects outside of the JVM. Is this something that could possibly be the fault of my program, or should I just ignore it and attribute it to some problem with his computer?
For a Java application to crash the OS it runs on, there must be a bug in the JVM. That said there are situations that can give the same impression:
the Java application can grow its heap far enough that the OS starts to swap and other applications appear to slow down to a halt
the Java application can grab all CPU by one or more threads in a tight busy loop
If you can setup your testers' machine so that a heap dump can be triggered when the problem occurs, you can analyse that dump remotely. For instance with IBM's Java heap analyzer found on alphaworks.
There were cases before of crashes under windows on IBM Thinkpads (and other machines I am sure) due to a bad graphics driver. I'd suggest doing the usual thing of making sure the drivers are up to date just to be on the safe side.
While your code may not use JNI directly a lot of what happens under the hood can (anything that integrates with the underlying OS essentially). Which means drivers can be a big problem.
The other thing would to be sure that the most recent version of the Java is being used (if 1.6_17 isn't possible at last the latest version of the version of Java being used).
One other thing that has fixed random crashes for me is to re-seat the memory (unplug it and plug it back in).
he said it freezes everything in Windows (his mouse doesn't even move)
A user-mode application — whether Java or otherwise — can't do that against a modern OS like WinNT.
He either has a hardware problem, or a bad driver.
To crash the entire computer, try this:
public void crashComputer() {
while(true)
new Thread(new Runnable() {
#Override
public void run() {
while(true) {
crashComputer();
}
}
}).start();
}
public void crashJVM() {
while(true)
crashJVM();
}
The crashComputer function takes about 2 seconds to crash the entire computer. You can stop it from crashing by holding power button.
The crashJVM function crashed only the JVM by overloading the stack, causing a stack overflow (That's where the name of this website comes from).
WARNING: Use at your own risk. This will not damage your computer, but I'm not taking the blame if you forget to click save on a document or something.
Also check the page file space on the client (Windows/XP) system.
Point one: On my XP, SP3 system, when any program runs full tilt, it almost locks up the computer. When my anti-virus program checks for updates, everything else stops for all practical purposes, and it uses very little CPU (seems to be writing to disk all the time). My own infinite loops, using 100% CPU, have a similar effect. (Why the task manager does not get priority over a user program with "normal" priority I do not know.)
Point two: On any computer I've ever used, heavy paging will bring a program to an almost complete stop.
So start with an XP computer with 512Mb of real memory and 2000Mb of virtual memory. Write a Java program with 1400Mb worth of arrays and other data structures. Put in a loop that repeats several billion times and reads or writes to each byte in that 1400Mb on each execution. This program will not finish until long after the universe collapses in on itself. The computer will do nothing. I have not tried this and I do not intend to, but I will bet anything even the mouse won't move. Depending on the make of the computer, the only fix may be pulling the power plug out of the wall socket. (Note that technically, the computer has not crashed. Indeed, it is working just fine. But you are going to need to be patient. Move the mouse the day before you plan to click.)
The moral of this story is to avoid both XP and virtual memory, but if you have to deal with either, be aware of these problems.
[UPDATE: I forgot to add that this 30 sec. freezing problem only happens the first time I try to load a file from the server. Subsequent loads are very quick. Maybe some strange reverse DNS lookup? I am hosting on Google's appengine.]
I started a little project recently called http://www.chartle.net which is build around an applet.
Startup time is an important factor in the user's experience of an applet. I collect statistics and am shocked that I find often very long startup times (factor 50 to 100 higher then necessary)
The applet starts in 1-3 seconds depending on the speed of your computer and connection. Still for some users it takes up to 100 sec.
I have mixed results from my own tests. Mostly it is very fast but sometimes freezes the browser for a long time and the Java console doesn't tell me why. Best guess is, that it stalls when loading a saved chart.
Please help me figuring this out - best test by opening an already saved chart (click on one of the 'create' links at http://www.chartle.net/gallery)
Cheers,
Dieter
This is generic help rather than specific for your demo (which loaded fine for me in a few attempts).
Freezing applets
In the JDK bin directory there is a very handy programme called jstack. Refresh your browser window until it crashes and then run:
jstack *process_id*
This will give you the stack trace of any frozen Java process. If Java is not a separate process then you can use the browser's process (eg for Opera).
The following few problems were/are common for me:
I reccommend you use invokeLater rather than invokeAndWait on the init method (although you can't do this if you use start/stop methods)
Opera's custom java plugin acts very poorly...
Deadlocks caused by synch blocks and invokeAndWait's
Slow applets
Possibly the browser is fetching resources from the server, unable to use the jar file?
It may be that only the old plugin causes these problems. That means basically all people running on OSX and other users with Java prior to 1.6_update_10.
So, I would really appreciate people with such setups to watch their Java console and describe the first startup behaviour.
Cheers,
Dieter
I'm trying to get to the bottom of a problem with our Java applet based program. It quite regularly seizes up with an unresponsive GUI (or a white screen). This of course only happens when deployed at a customer site :-(. They are running a version of the Sun JVM in 1.5 series (not sure the exact release).
We have a theory that it's to do with the applet running out of heap space - does that sound plausible? The other thing that I have set up on my machine is disabling direct draw, but that was mainly to avoid weird artefacts on other applications.
They are seeing the problem on Citrix and on regular PCs, but obviously there is a limit to what the users on Citrix can do.
Any suggestions?
Running out of heap space should cause an OutOfMemoryError to be thrown. This case sounds like a typical deadlock. To find where that is you want a stack dump of all the threads. IIRC< you can do it through the console, or from IIRC 1.6 the JDK includes jps and jstack.
First of all ensure the customer uses the latest release of the JVM they are using, and make them enable the Java console inside their browser (this requires some research from you).
Then when it happens again, tell them to look at the console window and cut-paste the contents in a mail to you.
In order to solve the problem, you must first be able to reproduce the problem. You will need an identical system in order to troubleshoot this, making one change at a time while keeping everything else equal to determine the cause(s).
Just to add to this answer (to build the knowledge base as I'm currently looking into this).
There's (at least) 2 distinct white screens related to applets.
Deadlock (as mentioned by Tom) - area will not refresh when you drag a window in front of it, so you get the strange tails left effect.
VM crash - area will become white, Java VM closes (search for hs_err_pid*.log, location dependent on browser)