We have a java based application that runs as an applet in internet explorer. One of the things that this applet does is load a dll that is used to launch a third party piece of software. One of our clients has deployed our application in a Citrix environment. Only with this client, (who is also the only one running Citrix) do we see a problem where, intermittently, CPU spikes on the Citrix server to 100%. When we use process explorer to see what is happening, I see that the culprit is MSVCR71.dll. How do I solve this problem?
After almost five weeks of effort, I found the answer to this problem. It had nothing to do with Citrix, nor did it have to do with loading a third party piece of software. What happened was that I was disposing a JDialog box twice. The second time I disposed it, the system seized and spiked the CPU.
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.
Thank you for viewing my post.
I'm running selenium-server-standalone as a windows service utilizing nssm(- the Non-Sucking Service Manager | http://nssm.cc/), utilizing the identical process as mentioned in this stackoverflow post #: https://stackoverflow.com/a/10656979/956863.
Quick Summary of post:
Download and extract nssm.exe
Installed NSSM and from the command line ran: nssm install Selenium-Server "C:\Program Files\Java\jre6\bin\java.exe" "-jar C:\Selenium\selenium-server-standalone-2.24.1.jar"
The machine where I'm running this process is running windows XP, service pack 3. This solution to run selenium server as a service works like a charm, and when selenium server is running, and crashes for some reason, selenium server successfully restarts without manual intervention.
But I"m coming into work, and am being informed by system administrators that high cpu alerts are being thrown. And again system logs are providing no information... So I'm wondering if selenium is actually the cause of this issue, and want to eliminate the possibility of running selenium as a service being blamed for this cpu spike.
Can anyone think of a solution, perhaps a way to stop the selenium service when cpu utilization reaches X amount? Or?
In the meantime, I'm going to set some sort of long term CPU utilization monitor and see if that can see something that the system monitor in xp may be missing. ( If anybody knows of a good way to achieve this, i'm open to suggestions as well )
I have selenium running as a service on windows 2008 server and noticed that its not able to clean up the headless browser instances. My tests are written in JavaScript with Soda so I have a start up and close out the browser instances but running as a service it doesn't close out those instances in the task manager.
I actually have two ways I'm running the service one way is where I'm using a bat file to run selenium the other way I have it running directly off a registry key.
I was able to fix the browser issue after I just added another step process to teamcity to run taskkill automatically on any browsers left open when the tests were complete. This fixed my CPU spiking issue.
Despite having vague reports of CPU spikes with Selenium as a service, I have yet to see one with my own eyes. Which version of Java are you using?
Our commercial run-anything-as-a-service product supports CPU tracking and can restart Selenium when it hogs the CPU. I suggest that you download the free 30-day trial and use it see if you can confirm or rule out Selenium as the problem in that time frame. Follow this guide to set up Selenium as a service.
I am in the process of development of a stand-alone (Swing) Java EE client. The application server is JBoss 6.1.0. Some Windows workstations freeze while the client is running, some do not. Both 32-bit and 64-bit Windows workstations freeze, and again, some 32-bit and 64-bit Windows workstations work perfectly. The client runs well on Linux without any problems.
I have followed instructions from StackOverflow where people suggested to disable direct draw with -Dsun.java2d.noddraw=true. It did not help.
What puzzles me the most is that some workstations are almost identical - the same Windows version, the same graphics drivers, the same JRE, yet some work well, some do not.
The application uses the Preferences API a lot to store various positions of dockables (from the Docking Frames project), it uses JBoss client classes.
I am in the process of investigating if perhaps concurrent access to the Windows registry is causing this problem (if you had similar problems please let me know)...
First guess was that a race condition occurs somewhere in the GUI thread, and the GUI freezes. But that would freeze only the GUI, it should not freeze the whole Windows.
The machine, once frozen, responds to pings, however no Windows service works.
I would appreciate any hint that can help me solve the problem.
Edit:
CPU usage is always around 10%.
Number of threads never goes above 30, however not all threads are daemon threads (this includes AWT threads, RMI threads, etc).
Try out the EventQueue with Watchdog. You install an alternative EventQueue in the Application. The Watchdog tells you which Events are locking up your GUI.
It turned out to be ESET. On every Windows machine that had ESET installed I had this problem. Apparently ESET has this "protocol tracking" feature that is ON by default. Once turned off we never had this problem.
I have a java application that I run from eclipse 3.5.
My OS is WinXP(SP2) and the JRE version is 6.05.
I run the application on two identical computers (or so I think) but the application behaves differently on each computer.
The computers are the same Dell Optiplex model with the same amount of memory and have the same GPU.
On the first computer, the application runs flawlessly. However, on the second one the application freezes for a couple of minutes and then returns to run normally.
The strange thing is that the CPU usage on the second computer is not high at all. It seems as though my application does not receive any CPU for no apparent reason.
Computers should be deterministic so I assume there must be some difference between the machines but I don't know where to look.
I would love some ideas on where the problem might be.
Thanks,
Yoav.
I've found the problem.
The application that was unresponsive was run in debug mode.
Sorry to have wasted your time...
It may help you to get a Thread Dump when the app freezes. This will hopefully tell you exactly what is holding you up (i.e. waiting for IO somewhere).
Well, I would first update your JRE version as there are newer versions now.
As for both computers being identical, are they really identical? I find it difficult to believe that both have the same exact software and setup and that anything you have done to one, you have always done to the other. If this is indeed the case, you may want to try to debug your application on the second machine (the one that hangs) and find out specifically where it hangs.
It may also help us if you give more information about your application. The problem may not be your computer at all if the application is doing things like web access, network access, etc.
So both computers have nearly identical hardware. A few other things to check
Do they both have Eclipse 3.5, WinXP(SP2) and JRE 6.05 installed?
And behave differently when run from within Eclipse (on both machines or on one run from command-line)?
Is this reproducible? If yes When does it happen? On startup? Or on some specific action?
Does the program have a GUI?
Is there maybe some kind of virus scanner or another comparable software installed on one of the machines which could delay the program
Is networking, file acccess, multithreading involved?
I can think of two non-application possibilities:
Memory Paging. There's something extra happening on the slow machine, so your JVM is not getting a fair share of CPU time. A large daemon process or some such.
Network access. Your app is making some kind of network call and it's glitching or timeing out. Perhaps going and fetching some XML schema, perhaps a disk acesss to a mounted drive.
I've seen all manner of weirdness when apps attempt to access hosts by name and DNS is not well. One machine has an etc/host entry the other does not. Even each machine might want to resolve itself.
[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