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

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Deployment-Debugging Frozen Deployed Instances
1 +Web Applications-Deployment-Debugging Frozen Deployed Instances
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.apl
Content
... ... @@ -94,20 +94,6 @@
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 -
111 111  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.
112 112  
113 113  {{noformat}}
... ... @@ -142,7 +142,3 @@
142 142  = Conclusion =
143 143  
144 144  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]]