Skip to Content
Last modified by David Avendasora on 2010/11/30 06:59
From version 15.1
edited by David Avendasora
on 2010/11/30 06:59
Change comment: There is no comment for this version
To version 16.1
edited by David Avendasora
on 2010/11/30 06:59
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -2,7 +2,7 @@
2 2  
3 3  A current app I'm working freezes up for about a minute when calling editingContext.saveChanges. The following message is added to the system output:
4 4  
5 -{{code value="none"}}
5 +{{code 0="none"}}
6 6  
7 7  <WorkerThread3> <WOWorkerThread id=3 socket=Socket[addr=/xxx.xxx.xxx.xxx,port=51634,localport=51563]>
8 8  Exception while sending response: java.net.SocketException: Broken pipe
... ... @@ -24,14 +24,12 @@
24 24  * Increase the Connect Timeout and Receive Timeout values in JavaMonitor so that the woadaptor will wait long enough for your application to provide the response.
25 25  
26 26  {{note}}
27 -
28 28  If this message happens in other contexts (i.e. not when a request takes a long time to process) it might just mean that the user hit stop in their browser or clicked another link.
29 -
30 30  {{/note}}
31 31  
32 -== Where's my stderr? ==
30 +== Where's my stderr!? ==
33 33  
34 -Wotaskd launches new WOA instances using a script called SpawnOfWotaskd.sh that is located in /System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh on OS X. For some reason, this script was written to throw away stdout and redirrect stderr to stdout. This means that if you ever want to get a thread stack dump, you're out of luck. Fortunately this is an easy fix. If you edit SpawnOfWotaskd.sh, the stock version looks like:
32 +Wotaskd launches new WOA instances using a script called SpawnOfWotaskd.sh that is located in /System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/SpawnOfWotaskd.sh on OS X. For some reason, this script was written to throw away stdout and redirrect stderr to stdout. This means that if you ever want to get a thread stack dump, you're out of luck. Fortunately this is an easy fix. If you edit SpawnOfWotaskd.sh, the stock version looks like:
35 35  
36 36  {{code}}
37 37  
... ... @@ -40,7 +40,7 @@
40 40  
41 41  {{/code}}
42 42  
43 -Notice that stream 1 goes to /dev/null, and stream 2 writes to stream 1. Boo. Change it to:
41 +Notice that stream 1 goes to /dev/null, and stream 2 writes to stream 1. Boo. Change it to:
44 44  
45 45  {{code}}
46 46  
... ... @@ -49,16 +49,16 @@
49 49  
50 50  {{/code}}
51 51  
52 -The one problem now is that typically WebObjects apps run as appserver user, which means they won't be able to write to this file. To fix this, you can 'touch /var/log/webobjects.err' as root, and then chown the blank file to whatever user your WebObjects apps run as.
50 +The one problem now is that typically WebObjects apps run as appserver user, which means they won't be able to write to this file. To fix this, you can 'touch /var/log/webobjects.err' as root, and then chown the blank file to whatever user your WebObjects apps run as.
53 53  
54 54  == Can't connect to window server - not enough permissions ==
55 55  
56 -Ah yes, the joys of AWT. If you touch any AWT class (event the ones that don't make sense, like Dimension, or Rectangle), an AWT Toolkit will be created (in a static block) and AWT will attempt to connect to the window server. Of course when you ran in development mode, you had access to the window server and everything was peachy. As soon as you tried to deploy as the appserver user, all hell broke loose. You have a couple of options for fixing this one:
54 +Ah yes, the joys of AWT. If you touch any AWT class (event the ones that don't make sense, like Dimension, or Rectangle), an AWT Toolkit will be created (in a static block) and AWT will attempt to connect to the window server. Of course when you ran in development mode, you had access to the window server and everything was peachy. As soon as you tried to deploy as the appserver user, all hell broke loose. You have a couple of options for fixing this one:
57 57  
58 -* Just stop using them. This is the most sure fire way to not get hit by this problem. Don't use AWT classes when you don't need to. Obviously this is often easier said than done.
59 -* Add Djava.awt.headless=true to your VM launch parameters. This tells AWT to use headless mode. If you are using older versions of Apple's JVM, this may still cause issues (weird debug statements requesting for you to hit a key on the console).
60 -* [[PJA Toolkit>>http://www.eteks.com/pja/en/]]. This is actually kind of a cool library. It's a pure java implementation of an AWT toolkit. On a normal system, your AWT implementation is JNI (to talk to your native window system). PJA provides pura java implementations of all of the capabilities a normal AWT toolkit would attempt to perform. Obviously it doesn't actually use the window server, rather it's working akin to a VNC server with a virtual frame buffer.
61 -* Run as root. This is not generally recommended, but you can modify your /System/Library/StartupItems/WebObjects/WebObjects script to run WO as root instead of appserver user. You'll find the instructions on doing so inside of that script.
56 +* Just stop using them. This is the most sure fire way to not get hit by this problem. Don't use AWT classes when you don't need to. Obviously this is often easier said than done.
57 +* Add -Djava.awt.headless=true to your VM launch parameters. This tells AWT to use headless mode. If you are using older versions of Apple's JVM, this may still cause issues (weird debug statements requesting for you to hit a key on the console).
58 +* [[PJA Toolkit>>url:http://www.eteks.com/pja/en/||shape="rect"]]. This is actually kind of a cool library. It's a pure java implementation of an AWT toolkit. On a normal system, your AWT implementation is JNI (to talk to your native window system). PJA provides pura java implementations of all of the capabilities a normal AWT toolkit would attempt to perform. Obviously it doesn't actually use the window server, rather it's working akin to a VNC server with a virtual frame buffer.
59 +* Run as root. This is not generally recommended, but you can modify your /System/Library/StartupItems/WebObjects/WebObjects script to run WO as root instead of appserver user. You'll find the instructions on doing so inside of that script.
62 62  
63 63  == Java Monitor Issues ==
64 64  
... ... @@ -71,15 +71,15 @@
71 71  
72 72  == WOtaskd Didn't Start ==
73 73  
74 -In older versions of OS X server, WOtaskd and JavaMonitor were launched using the StartupItems system. In more recent versions of OS X server and WebObjects, Apple uses its new launchd framework instead. If you install WebObjects with developer tools, you typically only end up with the Startupitem scripts, so you should follow those instructions.
72 +In older versions of OS X server, WOtaskd and JavaMonitor were launched using the StartupItems system. In more recent versions of OS X server and WebObjects, Apple uses its new launchd framework instead. If you install WebObjects with developer tools, you typically only end up with the Startupitem scripts, so you should follow those instructions.
75 75  
76 76  === WOtaskd/WOMonitor LaunchDaemon ===
77 77  
78 -For an overview of launchd, you can read [[Apple's documentation>>http://developer.apple.com/macosx/launchd.html]].
76 +For an overview of launchd, you can read [[Apple's documentation>>url:http://developer.apple.com/macosx/launchd.html||shape="rect"]].
79 79  
80 80  The WebObjects launch daemon items are disabled by default, so the first thing you will need to do is enable them:
81 81  
82 -1. cd /System/Library/LaunchDaemons
80 +1. cd /System/Library/LaunchDaemons
83 83  1. edit "com.apple.womonitor.plist" and "com.apple.wotaskd.plist"
84 84  1. change the Disabled key from "true" to "false"
85 85  1. save and exit
... ... @@ -96,13 +96,13 @@
96 96  1. "start com.webobjects.womonitor"
97 97  1. Quit launchctl (ctrl-c it)
98 98  
99 -wotaskd and womonitor should now both be running. You can test monitor by going to [[http://localhost:56789]].
97 +wotaskd and womonitor should now both be running. You can test monitor by going to [[http:~~/~~/localhost:56789>>url:http://localhost:56789||shape="rect"]].
100 100  
101 101  If this does not work, check for file system permissions on /Library/WebObjects/Configuration, which should be appserver:appserverusr or at least they should have write permission to this directory.
102 102  
103 103  Running this following command in a terminal window will tell you exactly why wotaskd is not launching...
104 104  
105 -{{code title="Manually Launch wotaskd"}}
103 +{{code title="Manually Launch wotaskd" 0="none"}}
106 106  
107 107  sudo -u appserver /System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/Resources/javawoservice.sh \
108 108  -appPath /System/Library/WebObjects/JavaApplications/wotaskd.woa/wotaskd
... ... @@ -111,7 +111,7 @@
111 111  
112 112  === WOtaskd/WOMonitor StartupItems ===
113 113  
114 -On developer installs and older Mac OS X Server installs, WebObjects is launched using the old StartupItems system. By default, wotaskd and womonitor are disabled. Fortunately, enabling them is easy:
112 +On developer installs and older Mac OS X Server installs, WebObjects is launched using the old StartupItems system. By default, wotaskd and womonitor are disabled. Fortunately, enabling them is easy:
115 115  
116 116  1. cd /System/Library/StartupItems/WebObjects
117 117  1. Edit "WebObjects"
... ... @@ -125,18 +125,18 @@
125 125  
126 126  After these changes, wotaskd and womonitor will autostart after a reboot.
127 127  
128 -Note: Do not follow these instructions on a MacOS X 10.4. Server machine with WO 5.3.**. There, the process is started as LaunchDeamon (described above). If you enable the Startup Item, the system tries to start wotaskd twice which leads to nothing working at all.**
126 +Note: Do not follow these instructions on a MacOS X 10.4.* Server machine with WO 5.3.*. There, the process is started as LaunchDeamon (described above). If you enable the Startup Item, the system tries to start wotaskd twice which leads to nothing working at all.
129 129  
130 130  == Dealing with Deadlocks/Application Hanging ==
131 131  
132 132  There are several techniques for dealing with deadlocks and application hangs.
133 133  
134 -If you are using a [[profiler>>WO:Programming__WebObjects-Web_Applications-Development-Profiling_WO_Apps]] or debugger, you can generally pause execution and see where exactly your application is dying.
132 +If you are using a [[profiler>>doc:WO.Programming__WebObjects-Web_Applications-Development-Profiling_WO_Apps]] or debugger, you can generally pause execution and see where exactly your application is dying.
135 135  
136 -If you are using JDK 1.4, you can send your application a QUIT signal and it will dump all active threads. On OS X, find the pid of your application, then execute a 'kill QUIT yourAppPID'. The thread stack traces will dump out to the log files. If you do not see any output in your logs, see the //Where's my stderr?// above for possible reasons.
134 +If you are using JDK 1.4, you can send your application a QUIT signal and it will dump all active threads. On OS X, find the pid of your application, then execute a 'kill -QUIT yourAppPID'. The thread stack traces will dump out to the log files. If you do not see any output in your logs, see the //Where's my stderr!?// above for possible reasons.
137 137  
138 138  If you are using JDK 1.5, in addition to being to send the application a QUIT signal, you can also attach to it (as root or the launching user) and get the thread stack dumps using the 'jstack' application by calling 'jstack yourAppPID'.
139 139  
140 -If you see hangs in WOWorkerThreads waiting to restore a session, this generally means a previous request threw an exception from a location that didn't properly check its session back in. Session access in WebObjects is single-threaded. Common cases that can cause this are throwing exceptions from your awake methods as well as throwing exceptions from DirectAction methods.
138 +If you see hangs in WOWorkerThreads waiting to restore a session, this generally means a previous request threw an exception from a location that didn't properly check its session back in. Session access in WebObjects is single-threaded. Common cases that can cause this are throwing exceptions from your awake methods as well as throwing exceptions from DirectAction methods.
141 141  
142 -In JDK 1.4, you will be able to see the list of object locks that each stack trace is holding. You can find deadlocks by looking for multiple threads that contain two or more overlapping locks. In JDK 1.5, the VM detects deadlock situations and will identify them in the thread stack dumps.
140 +In JDK 1.4, you will be able to see the list of object locks that each stack trace is holding. You can find deadlocks by looking for multiple threads that contain two or more overlapping locks. In JDK 1.5, the VM detects deadlock situations and will identify them in the thread stack dumps.