Changes for page Troubleshooting Frozen Deployed Instances
Last modified by David Avendasora on 2010/11/30 06:43
From version 11.1
edited by Andrew Lindesay
on 2007/10/24 19:27
on 2007/10/24 19:27
Change comment:
There is no comment for this version
To version 14.1
edited by Jonathan 'Wolf' Rentzsch
on 2009/02/03 16:54
on 2009/02/03 16:54
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. apl1 +XWiki.rentzsch - Content
-
... ... @@ -94,6 +94,20 @@ 94 94 95 95 = What to Look For = 96 96 97 +##jdb##'s ##watch all## command will give you a stack trace for all threads in your app. But your process needs first to be suspended in order to get a coherent stack trace. Use it like so: 98 + 99 +{{noformat}} 100 + 101 +> suspend 102 +All threads suspended. 103 +> where all 104 +... 105 +> resume 106 +All threads resumed. 107 +> 108 + 109 +{{/noformat}} 110 + 97 97 An example of a stack trace is shown below. You'll notice the java class name and source-code line number at the end of a particular entry in the stack. Here we can see that the thread called "WorkerThread103" has stuck trying to get a session from the session store. In this situation another thread will most likely have the session store locked and is not releasing the lock. 98 98 99 99 {{noformat}} ... ... @@ -128,3 +128,7 @@ 128 128 = Conclusion = 129 129 130 130 Despite the simplicity of this approach, it provides for a means by which you can find out what is going on inside frozen instances rather than playing laborious guessing games. 145 + 146 += Alternative Approaches = 147 + 148 +[[http://www.gvcsitemaker.com/gvc.webobjects/faq&mode=single&recordID=41413]]