a log message containing the corresponding OutOfMemoryException would be a good starting point ;-)
Additionally you could use a profiler to analyze the memory usage of your application to spot a memory leak in the results. Perhaps you can track down the problem even with simple tools like jconsole or jvisualvm together with the server logs to narrow the part of your application causing the memory leak by watching which actions in the application are consuming so much memory.
Ravi Pavan wrote:The approach you mentioned(Using Proflers ) would be fine before check in into Repository . Now situation is out of my hand .
The OOM is typically caused by a piece of code in your application. So you cannot have a situation whereby it is out of your hand. Even if that piece of code is deployed to production and you found that it is causing the memory leak, you have got to fix it and release it.
Ravi Pavan wrote:Can you please tell me what is Thread Stuck mean ?
A thread will execute a request and by default, WLS will set a pre-determined duration, 600 seconds, as the threshold for the thread to finish the work. If for whatever reasons, the thread doesn't complete its work within 600 seconds, it is deemed to be "stucked" by WLS. This is however, just, an information/warning. There is a possibility that the thread cannot finish its work or it could be that the thread needs more time to finish its work. Looking through the logs, you may find that the thread becomes unstucked later on. Or if you don't, something is wrong. Look into the code that the thread is running, you may have to fix some bad coding or a bad design.