Skip to Content
Last modified by David Avendasora on 2010/11/30 06:43
From version 10.1
edited by Andrew Lindesay
on 2007/10/24 19:27
Change comment: There is no comment for this version
To version 13.1
edited by Pascal Robert
on 2010/09/12 23:38
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Web Applications-Deployment-Debugging Frozen Deployed Instances
1 +Deployment-Debugging Frozen Deployed Instances
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.apl
1 +XWiki.probert
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]]