Skip to Content
Last modified by Yana Oksner on 2026/01/08 11:45
From version 17.1
edited by David Avendasora
on 2010/11/30 06:43
Change comment: Migrated to Confluence 5.3
To version 19.1
edited by Yana Oksner
on 2026/01/08 11:45
Change comment: There is no comment for this version

Summary

Details

Page properties
Parent
... ... @@ -1,1 +1,1 @@
1 -Troubleshooting
1 +documentation.Home.Deployment.Troubleshooting.WebHome
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.avendasora
1 +XWiki.yanasd
Content
... ... @@ -25,11 +25,11 @@
25 25  
26 26  A WebObjects system which is deployed in the traditional manner consists of a number of copies of the program running separately, each carrying some of the inbound load from users. Each of these 'copies' is termed an instance. The {{code language="none"}}SiteConfig.xml{{/code}} file defines the instances. This configuration file is located at the following place in your MacOS-X Server's file system.
27 27  
28 -{{noformat}}
28 +{{code}}
29 29  
30 30  /Library/WebObjects/Configuration/SiteConfig.xml
31 31  
32 -{{/noformat}}
32 +{{/code}}
33 33  
34 34  Before you modify it, make a backup of the {{code language="none"}}SiteConfig.xml{{/code}} file in case anything goes wrong.
35 35  
... ... @@ -62,11 +62,11 @@
62 62  
63 63  Note that some JVM's on other platforms expect the "jdwp" to be specified as follows;
64 64  
65 -{{noformat}}
65 +{{code}}
66 66  
67 67  -agentlib:jdwp=transport=dt_socket,address=8121,server=y,suspend
68 68  
69 -{{/noformat}}
69 +{{/code}}
70 70  
71 71  = When Something Goes Wrong... =
72 72  
... ... @@ -78,19 +78,19 @@
78 78  
79 79  Use the {{code language="none"}}jdb{{/code}} command line tool that comes with the java environment to connect to the instance and debug it. To do this, enter a command of the following form on the application server.
80 80  
81 -{{noformat}}
81 +{{code}}
82 82  
83 83  fooserver$ jdb -attach 8121
84 84  
85 -{{/noformat}}
85 +{{/code}}
86 86  
87 87  If you want to debug a remote machine you can use the following command.
88 88  
89 -{{noformat}}
89 +{{code}}
90 90  
91 91  foodev$ jdb -attach woserverhost:8121
92 92  
93 -{{/noformat}}
93 +{{/code}}
94 94  
95 95  This may be useful in situations where your WebObjects application server does not have the {{code language="none"}}jdb{{/code}} tool installed and so you need to run the jdb tool from a host where the {{code language="none"}}jdb{{/code}} tool is installed.
96 96  
... ... @@ -100,7 +100,7 @@
100 100  
101 101  {{code language="none"}}jdb{{/code}}'s {{code language="none"}}watch all{{/code}} 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:
102 102  
103 -{{noformat}}
103 +{{code}}
104 104  
105 105  > suspend
106 106  All threads suspended.
... ... @@ -110,11 +110,11 @@
110 110  All threads resumed.
111 111  >
112 112  
113 -{{/noformat}}
113 +{{/code}}
114 114  
115 115  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.
116 116  
117 -{{noformat}}
117 +{{code}}
118 118  
119 119  WorkerThread103:
120 120   [1] java.lang.Object.wait (native method)
... ... @@ -139,7 +139,7 @@
139 139   [5] java.lang.Thread.run (Thread.java:552)
140 140  ...
141 141  
142 -{{/noformat}}
142 +{{/code}}
143 143  
144 144  If you have a look at what the other threads are doing at the same time, it is hopefully possible to ascertain what area might be at fault. At the very least, one can figure out what part of the application is at fault.
145 145