My feeling is that neither JDK 5 or 6 should exhibit this behavior. I have an app that is deployed under JDK6 that typically has 50 concurrent users hitting it every 30 secs 24x7 and I don't see this sort of issue. The only problem I've had is growth in the PermGen pool which eventually can cause an out of permgen exception, but that's after at least a couple of weeks, and does not exhibit as a freeze-up.
Yes, and I would see the permgen exception.
When you say it gets 'stuck', for how long does it get stuck?
Until it is reaped by our reaper, which runs every 20 minutes. If the reaper is running, I usually start getting calls from my users in about four-five hours.
Out of interest, are you using the client or the server vm?
The client vm - the server vm is even more unreliable, and it takes *ages* to start.
Could this just be a GC tuning issue? The client VM could spend a lot of time doing a garbage collect. How much RAM do you have in the machine, and how big is the Java heap? (-mx)
1 gig of RAM, and Java heap is 384M. However, there are multiple JVMs and tomcats running on this computer, so it's constantly out of RAM (No, I have no way of adding more RAM. It's a small, donated shuttle.)
It probably is a GC issue; now that you mention it, when the system is stuck and you connect to it with jconsole, it shows that heap is pretty much out.
So it appears that JDK6 is not collecting garbage as well as it should. /Janne
