tag:blogger.com,1999:blog-19212811.post3940004497959870398..comments2009-12-04T13:30:59.989-08:00Vidya Balasubramanianhttp://www.blogger.com/profile/02901404954837710621noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-19212811.post-48360340491444962152007-09-21T05:02:00.000-07:002007-09-21T05:02:00.000-07:00We have had similar problems on our live envrionemnt, usually caused by a Full Garbage collection running on the OC4J affected. We have allievated the problem somewhat by having more smaller OC4Js but we still haven't got rid of the problem completely.Mezzahttp://www.blogger.com/profile/10327069167930242211noreply@blogger.comtag:blogger.com,1999:blog-19212811.post-47967722426836515852007-09-20T19:44:00.000-07:002007-09-20T19:44:00.000-07:00I have the same issue now with 10.1.3.0 and an internal application that we have. We didn't deploy it with Jdev, just used the EM Console, and we've been seeing ping timeouts and force restarts in the opmn.log. Its been very difficult to troubleshoot, and Oracle has only said to make sure to test your application with JProbe and other testing methods. Logs give really know clue on what is happening, and I can only hope that as time goes on this can be improved to be equal with the database side of things that can manage the entire database and give you reports about virtually anything. Not so much at the moment with the JVM. Grid control can tell you about Memory, CPU, # of sessions, # of active requests, # of jdbc connections and such, but can't even get close to helping you identify poorly coded jsps, ejbs, servlets, etc. or tell you more specifically when a particular jsp was looping forever, ramped up in memory and crashed the jvm. I can only hope the management of the JVM improves to at some point give you these types of reports making it easier to find and fix the problem faster.davikeshttp://www.blogger.com/profile/04258661084288298130noreply@blogger.com