I would sugest that you analyse it with an jvm introspect tool. Im using byteman ( jboss.org/byteman ). You can write simple script to analyse when a class is istantiated. So if you have suspicious classes you can check its status on runtime. Hope that it can help
Hi Victor, Thanks for the suggestion. I will test with byteman to see if that can help my situation.
Jimy, you can configure your mod_jk to log more and you will see what was happening with the request (the logging will be however too verbose so not a good fit for production for sure).
If there are chances you can reproduce than surely +1 for Byteman if you want to instrument a class/method to do additional logging.
BTW "But there is no hs_error" - did the JVM user have permission to write it there? Make sure you are not calling System.exit() ;-)
Did you activated this option on your vm args?
Yes, configure the mod_jk in debug mode is too heavy and not possible for the live system. We did try to examine our code to make sure there is no System.exit().
Since there is frequently GC activities before it crash and the heap size looked ok, we did not set this option XX:+HeapDumpOnOutOfMemoryError , either. But I will set it to see if that helps.
So this issue happens relatively often in production env but you cant reproduce it? Ah, these are always hard to find in live system. Most likely this looks like memory issue, so make sure your system and your JVM are not running out of memory.
Sorry, I type incorrectly, there is NO frequently GC activities before it crash. And yes, not reproducible either. :-(
Will definitely try the byteman if I can get the breaking point.