Help

 

 

What are Monitor and wotaskd? (top)

Monitor and wotaskd are part of the WebObjects deployment strategy. Each machine that is running a WebObjects application should have the WebObjects Task Daemon (wotaskd) running on it. To configure these applications for deployment, the Monitor application should be run, but once configured, only the wotaskds need remain running. Each wotaskd is only responsible for all WebObjects applications running on the same host. The Web server adaptor (or WebObjects HTTP adaptor) communicates with the wotaskds on each host to discover what WebObjects applications are available. Instances communicate their state to wotaskd through the use of TCP lifebeats, while wotaskd controls instances through special DirectActions.

Monitor MUST be run from a machine that is both running wotaskd AND is a "managed" host.

NEVER run more than one Monitor for a set of Hosts.

ALWAYS run Monitor and wotaskd behind a firewall.





What is the difference between http://host:2001/cgi-bin/WebObjects/MyApp.woa, http://host/cgi-bin/WebObjects/MyApp.woa, and http://host/cgi-bin/WebObjects/MyApp.woa/-2001 ? (top)

A WebObjects application can be accessed 3 ways:
The first (http://host:2001/cgi-bin/WebObjects/MyApp.woa) is Direct Connect.
The second (http://host/cgi-bin/WebObjects/MyApp.woa) is through the Web server as a Deployment application.
The third (http://host/cgi-bin/WebObjects/MyApp.woa/-2001) is through the Web server as a Development application.

  • In Direct Connect, the browser is sending requests and receiving responses directly from the application; the Web server is not involved at all. Resources for the application (images, etc) are served by the application itself. The browser is connected directly to the port (2001 in the example URL) of the application. To use an application in Direct Connect does not require the use of wotaskd or Monitor.
  • When accessing a Deployment application through the Web server, a browser sends a request to the Web server (typically port 80). The Web server gives the request to the WebObjects HTTP adaptor, which passes it on to the application. The application's response is returned to the adaptor, which gives it to the Web server, which sends it to the browser. Resources for the application (images, etc) are served by the Web server, which requires a split install. Accessing an application through the adaptor provides several benefits: Pooling of connections, verification of requests, serving of resources, and load-balancing between multiple instances. Typically, applications are deployed through the Web server for security and performance reasons. Deploying an application using Monitor and wotaskd is described below.
  • Accessing a Development application through the Web server is similar to accessing a Deployment application, except that load-balancing between instances does not occur. Development applications make it possible to test an application through the Web server without fully deploying it. Accessing a Developer application is described below.





What is Load-balancing? (top)

Requests to an application through the Web server are load-balanced by the adaptor. In load-balancing, if the request is not directed at a specific instance of an application, it is assigned to an instance of that application chosen by the adaptor. Load-balancing takes place between instances with the same name (cf WOApplicationName). The default load-balancing scheme is Round Robin, but other load-balancing schemes are available. Round Robin distributes a request to instances one after another. Load Average attempts to balance load to the instances by evenly distributing the sessions between instances. If using the Random load-balancing scheme, an instance is chosen arbitrarily.





How do I set up an application for deployment through the Web server using Monitor? (top)

  1. Make sure the applications have been split-installed. (A copy of the WebServerResources directory should be located in the Web server document root in the path: /WebObjects/MyApp.woa/Contents/WebServerResources).
  2. Start Monitor (located in $NEXT_ROOT/Library/WebObjects/JavaApplications).
  3. Go to the Hosts page.
  4. Add the host that the WebObjects application(s) are on.
  5. Go to the Site page.
  6. Set the HTTP adaptor URL to the Web server adaptor URL.
  7. Go to Applications page.
  8. Enter the application name and click Add. The application name is the name that the Web server adaptors use to access the application. The name does not have to match the actual name of the application.
  9. In the Application Configure page, choose the path to the application, and any other defaults.
  10. Click Detail View.
  11. Add instances on the hosts. By default, they will be auto-recovered, and will start shortly after being added. If they are not auto-recovered, click the green button in the column "Start-Stop" to start the instances.
  12. Running instances are now accessible through the Web server.





How do I set up an application for development through the Web server? (top)

  1. Developer instances are instances that are not configured through Monitor/wotaskd. They are typically instances that are just started manually by a developer (either by hand or through Project Builder) for testing purposes. wotaskd should automatically pick up the existence of the instance and report it to the HTTP adaptor; the instance is then accessible through the local Web server for testing. Unregistered instances are never load-balanced by the adaptor. Unregistered instances may be accessed through the local Web server only; Web servers on other machines will not see them.
  2. Make sure the applications have been split-installed (the WebServerResources are located in the Web server document root).
  3. Start the application and note the port that it is running on. -WOPort can be used to set the port, and -WOApplicationName can be used to set the application name for the Web server adaptor.
  4. To access unregistered instances, the URL is:

    http://localhost/cgi-bin/WebObjects/<app name>.woa/<negative port number>





What HTTP adaptor settings are there? (top)

Most adaptor settings can be set at globally, on a per-application basis, and on a per-instance basis. When sending configuration information to the HTTP adaptor, Monitor first checks if the instance has a value set. If it doesn't, it checks if the application has a value set. If it doesn't it checks if there are global settings. If there are no global settings, it will allow the HTTP adaptor to use it's own defaults.
Load Balancing
The load-balancing scheme that the HTTP adaptor should use for instances of this application. The standard choices are Random, Round Robin, and Load Average. A custom load-balancer name may also be passed to the HTTP adaptor.
Retries
The number of times a request is retried if a communications failure occurs before an error page is returned.
Redirection URL
If an instance fails to respond to a direct request, this is the URL that the client is redirected to.
Dormant
After an instance fails to respond, the number of times the adaptor skips that instance before trying again.
Send Timeout
Seconds before the adaptor gives up trying to send data to an instance.
Receive Timeout
Seconds before the adaptor gives up waiting for a response from the instance.
Connect Timeout
Seconds before the adaptor gives up connecting to an instance.
Send Buffer Size
Size of the TCP send buffer on the connection to the instance from the HTTP adaptor.
Receive Buffer
Size of the TCP receive buffer on the connection to the instance from the HTTP adaptor.
Connection Pool Size
The maximum number of simultaneous connections a particular adaptor process should keep open to each configured instance.
URL Version
What WebObjects URL version the application responds to. All WebObjects 4, 4.5, and 5 applications use version 4 URLs by default.





How does the HTTP adaptor find instances? (top)

The HTTP (or Web server) adaptor finds instances through one of 3 mechanisms: Multicast, Host List or File. By default, Adaptors are configured to use a Host List of http://localhost:1085, and wotaskds do not respond to multicast. Configuration of the various HTTP adaptors is platform-specific, and is covered in the adaptor documentation.
NOTE: if changing the configuration for apache or cgi adaptors delete the WOAdaptorState file, typically located in /tmp/, before starting the Web server again.

In Multicast, the adaptor broadcasts a UDP request throughout its subnet. wotaskds that receive the request respond with their configuration URLs. Once the list of configuration URLs is gathered, configuration proceeds as in Host List. wotaskds do not respond to multicast broadcasts by default. The configuration style is

webobjects://<multicast address>:<port> <request interval>

In Host List, the adaptor requests a configuration file from each host in the Host List. The XML file provides a list of running Applications and Instances on that wotaskd. The configuration format is

http://<hostname>:<port>,http://<hostname>:<port>,<etc...> <request interval>

Host List is the default configuration mode, set to

http://localhost:1085 10"

In File configuration, the adaptor reads an XML file from the local file system that describes the application and instance configurations. The configuration format is

file://<path to WOConfig.xml> <request interval>

 

WOConfig.xml DTD

<?xml version="1.0" encoding="ASCII"?>

<!ELEMENT adaptor (application)*>
        <!ELEMENT application (instance)*>
                <!ATTLIST application 
                        name CDATA #REQUIRED
                        retries CDATA #IMPLIED
                        scheduler ( "RANDOM" | "ROUNDROBIN" | "LOADAVERAGE"
                                    | <!-- Custom Scheduler Name --> ) #IMPLIED
                        dormant CDATA #IMPLIED
                        protocol "http" #IMPLIED
                        redir CDATA #IMPLIED
                        poolsize CDATA #IMPLIED
                        urlVersion ( "3" | "4" ) #IMPLIED
                        additionalArgs CDATA #IMPLIED>
                <!ELEMENT instance>
                        <!ATTLIST instance
                                id CDATA #REQUIRED 
                                port CDATA #REQUIRED 
                                host CDATA #REQUIRED
                                sendTimeout CDATA #IMPLIED
                                recvTimeout CDATA #IMPLIED
                                cnctTimeout CDATA #IMPLIED
                                sendBufSize CDATA #IMPLIED
                                recvBufSize CDATA #IMPLIED
                                additionalArgs CDATA #IMPLIED>





How do I find the Web server URLs for Development instances if I don't know the port? (top)

The Adaptors can be configured to display an information page when requested. The URL is typically something like

http://localhost/cgi-bin/WebObjects/WOAdaptorInfo

A username and password may also be required:

http://localhost/cgi-bin/WebObjects/WOAdaptorInfo?user=u&password=p

Configuration of the Web server adaptors is platform-specific, and is covered by the adaptor documentation.





How does wotaskd know if an instance is alive? (top)

Instances update their status with their wotaskd by the use of lifebeats. Lifebeats are sent through a TCP/IP connection, and are sent every 30 seconds by default. wotaskd considers an instance "dead" when it has failed to send a lifebeat for 120 seconds (by default). Instances can also notify wotaskd of impending crash or manual stop by sending crash or stop messages. Lifebeats are sent from a separate thread, and should not interfere with or be affected by, normal request processing.





How does wotaskd control instances? (top)

Each wotaskd communicates with and controls its instances through the use of special DirectActions. There is a RequestHandler for each application, registered under the key "womp" that handles these administrative DirectActions. To prevent wotaskd from administering an application, invoke the following method in your WOApplication subclass constructor:

removeRequestHandlerForKey("womp");

Administrative DirectActions are not normally counted in instance statistics; to count them, programmatically invoke

requestHandlerForKey("womp").shouldAddToStatistics = true;





How do I tell whether wotaskd is running? (top)

There are two methods to find out whether wotaskd is running on a particular host. The first is to use the Hosts page in Monitor. The second is to open a browser and check the URL:

http://<host>:1085/cgi-bin/WebObjects/wotaskd.woa/wa/woconfig

which should return an XML file with the current configuration if wotaskd is running.





How do I prevent "false" instance deaths from being reported in Monitor? (top)

If wotaskd fails to receive a lifebeat from an instance for a set period of time, it marks that instance as dead. During periods of high load, there are several settings that affect this:
  1. Don't leave Monitor on the Detail View page with Auto Refresh active. This can be configured in the Preferences page of Monitor
  2. Change the default configuration interval for the HTTP adaptor from 10 seconds to something larger, such as 30 seconds. (adaptor configuration is platform specfic; see the adaptor documentation for details).
  3. Change the default lifebeat interval for the instances from 30 seconds to something larger, such as 60 seconds. This can be done in the Application Configurate page or the Instance Configure pages in Monitor.
  4. Change WOAssumeAppIsDeadMultiplier from the default of 4 to something larger, such as 6. This is a command-line flag passed to wotaskd upon startup.





What deployment-related arguments are there? (top)

Flags can be passed to an application on the command-line (-WODefaultName Value), or may be set in a file named Properties in the application's directory (typically AppName.woa/Contents/Resources/Properties). The Properties file should be in Java format (1 key-value pair to a line, with the format being key=value - use true or false, not YES or NO).

Monitor and wotaskd specific defaults
WODeploymentConfigurationDirectory
Each wotaskd writes its current configuration to disk whenever a change is made. It writes the SiteConfig.xml file in the directory specified by this default. The default value for this is $LOCAL_ROOT/Library/WebObjects/Configuration/. This, along with -WOLifebeatDestinationPort, allows for running multiple wotaskds on a single machine. This directory is also where wotaskd writes its adaptor configuration file (WOConfig.xml) if requested.


wotaskd specific defaults
WORespondsToMulticastQuery
Controls whether a given wotaskd should respond to multicast-configuration queries from the HTTP adaptor. Defaults to false.
WOSavesAdaptorConfiguration
Controls whether a given wotaskd should write an HTTP adaptor configuration file (WOConfig.xml) to disk. Defaults to false.
WOMulticastAddress
Allows users to specify a different multicast address for wotaskd to expect multicast queries on. Defaults to 239.128.14.2
WOAssumeApplicationIsDeadMultiplier
Allows users to specify the amount of time that wotaskd waits for a missing lifebeat before marking an instance dead. It specifies a multiplier against the WOLifebeatInterval, defaulting to 4x (so the default interval would be 120 seconds).


General Application Defaults
WOMonitorEnabled
Determines if the instance is being monitored by a wotaskd. Monitor sets this to true automatically when it starts an instance. It normally defaults to false.
WOLifebeatDestinationPort
Sets the port that lifebeats should be sent to. More generally, this is the port that wotaskd is running on; Monitor should use this default if wotaskd is running on a port other than 1085. Defaults to 1085, and is automatically set for any instance started by wotaskd.
WOLifebeatEnabled
Determines whether the instance should send lifebeats or not. Defaults to true, but fails after 5 consecutive attempts to send a lifebeat. Automatically set for any instance started by wotaskd.
WOOutputPath
Allows output for an instance to be redirected to the file specified by this default. Setting the path to /dev/null causes the application to swallow its output. Otherwise, it implies that all output should be written to the specified file. If the file doesn't exist, or can't be written to, treat as /dev/null. Defaults to nothing (output is generated normally).
WOLifebeatInterval
Allows users to set the time between lifebeats sent to wotaskd. It defaults to 30 seconds.
WOApplicationName
Allows wotaskd to set the value of Application.name(), to properly register lifebeats. The adaptor will only load-balance between instances with the same name; thus WOApplicationName can be used to create "groups" of instances, even if the instances have the same executable name. Defaults to the executable name. Set automatically for instances started by wotaskd.
WOHost
Allows applications to specify which network interface they should bind to when running. This option should only be used on hosts with multiple network interfaces (IP addresses). Set automatically for instances started by wotaskd. Thus, this property should be set only for wotaskd and Monitor.





How do I run multiple wotaskds on a host? (top)





What instance defaults and settings are available through Monitor? (top)

Path
The path to the application executable - this must be the full path to the executable inside the '.woa' directory. There are three default paths: MacOSX, Windows, and Unix (cf Hosts Page). When an instance is created, it chooses the Path appropriate to the type of Host it is on. No Default.
Auto Recover
If the instance crashes or is shut down, Monitor restarts it. Monitor also starts the instance upon startup. This setting doesn't apply to scheduled instances. Defaults to true.
Minimum Active Sessions
If an instance is set to Refuse New Sessions, the instance exits when the number of sessions is less than or equal to this number. Defaults to 0.
Caching Enabled
Determines whether component caching is enabled. -WOCachingEnabled. Defaults to true.
Debugging Enabled
Is debugging output enabled. For WebObjects 5.x applications, this is equivalent to setting Debug Level to at least Informational, and adding the WebObjects Debug Group. -WODebuggingEnabled. Defaults to false.
OutputPath
Output from the instance can be redirected to a file on disk. (cf Path for explanations of MacOSX/Windows/Unix). Should be the path to a directory - each instance automatically has its output filename set to 'AppName-ID'. -WOOutputPath. Defaults to nothing; output is not saved.
Auto Open In Browser and Auto Open Client Application
When an instance is started, should it automatically open a browser to its main page. JavaClient applications will automatically open a client application. -WOAutoOpenInBrowser and -WOAutoOpenClientApplication. Defaults to false.
Lifebeat Interval
How often should lifebeats be sent back to wotaskd/Monitor. -WOLifebeatInterval. Defaults to 30, typically shouldn't be changed.
Additional Arguments
These are additional arguments passed to the instances upon startup. NOTE: To pass Java properties that contain spaces, use "-Dkey=the value" (including quotes).





What application settings are available through Monitor? (top)

Name
Application names may only contain alphanumeric characters ('-' and '.' are allowed as well). The application name in Monitor does not need to match the name of the actual application's executable. Load-balancing in the adaptor takes place between instances that have the same name in wotaskd. (cf WOApplicationName).
Starting Port
New instances are assigned the next port number higher than the starting port that doesn't conflict with another instance (from any application). The port number can also be set on an instance by instance basis. Defaults to 2001.
Time Allowed for Startup
The amount of time the Monitor waits for an instance to start before it decides the instance has failed to start. Defaults to 30 seconds.
Phased Startup
After wotaskd launches, it starts up auto-recovered instances of this application one at a time, instead of all at once. Defaults to false.
Adaptor
The default adaptor an instance should use. This is not the HTTP adaptor used by the Web server, but rather the internal object that distributes connections to WOWorkerThreads. Defaults to WODefaultAdaptor, and normally should not be changed. -WODefaultAdaptor.
Minimum Adaptor Threads
The starting number of WorkerThreads the WODefaultAdaptor should create to handle incoming requests. This setting applies to the WODefaultAdaptor for WebObjects 5.x. -WOWorkerThreadCountMin. Defaults to 16.
Maximum Adaptor Threads
The maximum number of WorkerThreads that the default adaptor should create to handle incoming requests. As the load on an application instance grows, the WODefaultAdaptor will create new WorkerThreads to handle requests. This setting only applies to the WODefaultAdaptor for WebObjects 5.x. Setting this to -1 will let the number of WorkerThreads grow indefinitely. -WOWorkerThreadCountMax. Defaults to 256.
Adaptor Threads
The number of WorkerThreads that the default adaptor should create to handle incoming requests. This setting only applies to the WODefaultAdaptor for WebObjects 4.5.x. This is DEPRECATED for WebObjects 5.x applications. -WOWorkerThreadCount. Defaults to 8.
ListenQueue Size
The number of unhandled incoming connections that an instance can have. -WOListenQueueSize. Defaults to 128.





What is Instance Scheduling? (top)

Each instance can be independantly scheduled using the Application Configure page. During scheduling, an instance is restarted at regular intervals.

Graceful Scheduling
If an instance is gracefully scheduled, rather than shutting down immediately, it refuses new sessions. Existing sessions continue as normal. Once the number of active sessions drops to the Minimum Active Session Count (typically 0), the instance is restarted. If this option is not selected, the instance restarts at its scheduled time, terminating active sessions.
Hourly Scheduling
The instance is restarted ever X hours, with calculations starting at Y O'Clock. (Ex. Every 6 hours, starting at 3am means the instance would restart at 3am, 9am, 3pm, 9pm every day).
Daily scheduling
The instance is restarted at X O'Clock every day. (Ex. At 3am every day).
Weekly Scheduling
The instance is restarted at X O'Clock, on a particular day every week. (Ex. Every Sunday at 3am).





What does "Bounce" do to an application? (top)

"Bounce" restarts an application gracefully. It does so by starting at least one inactive instance per active host (or 10 % of the total active instance count), waiting until they have started, then refusing sessions for all old instances and turning scheduling on for all but the number of instances we started originally. The next effect should be that the new users get the new app, old instances die in due time and then restart when the sessions stop.
You must have at least one inactive instance in order to perform a graceful bounce.
You may or may not need to set ERKillTimer to prevent totally long-running sessions to keep the app from dying.





Monitor's Hosts page (top)

A host is only available if it is running a wotaskd daemon of the correct protocol (WebObjects 5.x). If available, clicking the YES hyperlink displays the current configuration of that host, including its SiteConfig, startup options, and its response to various HTTP server requests.

Add Host
Hosts may be added by short hostname, fully qualified hostname, or IP address. Hosts may be added of type MacOSX, Windows, Unix (this is used in determining the type of Path and Output Path chosen by an Instance on the host).





Monitor's Detail View page (top)

The Detail View page may be set to refresh at regular intervals, or not at all, in the Preferences page. The default is to refresh the page every 60 seconds. The page may also be manually refreshed by clicking Refresh Now.
Hyperlinks for active instances are generated using the HTTP adaptor URL from the Site Configuration Page.

Application Name
If any instances of this application are on, this is a link to the application URL, using the HTTP adaptor URL from the Site page. If the Http adaptor URL isn't set, http://localhost/cgi-bin/WebObjects is used instead. The request is load balanced.
Each instance has the following displays:
Name-ID
If the instance is active, this is a link to that instance through the HTTP adaptor. If the adaptor URL is not set through the SiteConfigure page, the default is "http://localhost/cgi-bin/WebObjects". This will open a new browser page. The request is not load balanced through the adaptors, it is sent directly to the instance.
Host-Port
If the instance is active, this is a link to the instance in "Direct Connect" mode, not through the Web server. This will open a new browser page.
Status
Green is On, Red is Off, Sweeping Up is turning on and Sweeping Down is turning off.
Start-Stop
Click the Green button to start, the Red button to stop the instance.
Auto-Recover
Is the instance configured for Auto-Recovery; clicking changes the state. Scheduled instances are always auto-recovering, and will show a Yellow ON.
Refusing New Sessions
Is the instance Refusing New Sessions; clicking changes the state. Scheduled instances show Yellow, and cannot be controlled manually.i
Scheduling State
Is the current instance scheduled; clicking changes the state.
Statistics
Displays the statistics for that instance. Clicking WOStats brings up a new browser window showing detailed statistics. Deaths shows the number of unexpected deaths for this instance (this doesn't include manual shutdowns or scheduled shutdowns). Clicking the number links to a page with the times of each crash.
Config
A link to the configuration page for that instance.
Delete
Deletes the instance.
All the instances may also be controlled simultaneously (ALL INSTANCES):
Start-Stop
Click the Green button to start all instances, the Red button to stop all instances.
Auto-Recover
Click the Green button to enable all instances for Auto-Recovery, the Red button to disable.
Refusing New Sessions
Click the Green button to set all instances to Refuse New Sessions, the Red button to allow all instances to Accept New Sessions.
Scheduling State
Click the Green button to enable scheduling for all instances, the Red button to disable scheduling for all instances.
Statistics
Displays the total statistics for all instances. Below the WOStats button is a calculation of transactions per second for the application as a whole. The Clear Deaths link will clear Death Histories for all instances.
Config
A link to the configuration page for the application.
Add X instances to host Y
Adds the requested number of instances to run on a particular host.





Deployment FAQ (top)

Q: My application is starting on the wrong IP address!
A: Use -WOHost <hostname or IP address>. This will force the application to bind to a particular IP address. If you are using Monitor/wotaskd, make sure that both are started with the same -WOHost argument - wotaskd will make sure that any instances it starts will have the correct WOHost setting.

Q: When I run an application, everything seems fine, but none of my pages get rendered! In particular, everything is returning without the opening bracket (<) in the HTML code.
A: You are using an older version of the Java runtime. WebObjects requires at least a 1.3.1 runtime (both the VM and the standard libraries).

Q: When I build an application on Windows, and move it to Solaris/MacOSX, it won't run - I get a permission denied error.
A: The launch script is probably not executable. Executing the command cd MyApp.woa; chmod a+x Myapp fixes the problem.

Q: When I invoke (Application) WOApplication.application(), I get a java.lang.ClassCastException: com.webobjects.appserver.WOApplication.
A: In your subclass of WOApplication, you must have the lines:
public static void main(String argv[]) {
    WOApplication.main(argv, Application.class);
}

Q: Applications won't start from Monitor, but they seem to start OK from the command line.
A: It's likely that you have a hostname defined in the DNS, and have an IP address, but your /etc/hostconfig lists your hostname as -AUTOMATIC-. Change -AUTOMATIC- to your actual hostname. You need to restart your computer for this to take effect (though a kill -HUP of inetd might work as well).

Q: I'm having trouble with the adaptor. How do I get more information about what's happening?
A: Enable adaptor logging -- in the temp directory of the HTTP server (/tmp on Solaris/MacOSX, execute echo $TEMP to find it on Win2k) create an empty file named logWebObjects, owned by root. The adaptor log will be created in the same directory, and will be named WebObjects.log. The adaptors do not need to be restarted in order for logging to start or stop.

Q: I launch an application instance from Monitor, but the launch fails after 30 secs. Monitor then tries to launch the application again repeatedly, taxing system resources. After a little while, the new instances eventually die, and my original instance eventually comes up.
A: Your application likely takes longer than 30 seconds to launch. In Monitor, set Time For Startup to a larger number (roughly the time it takes for your application to start + a little leeway).

Q: Can I use 4.5.x and 5.x on the same machine?
A: The only supported mixed deployment is 4.5.1 Deployment + 5.x Deployment. No mixed developments are supported. In addition, in a mixed 4.5.1/5.x deployment, only the 5.x tools (wotaskd and Monitor) should be used.

Q: What is the difference between the 4.5.1 and 5.x HTTP adaptors?
A: Only bug-fixes. In general, the most recent adaptors should be used, regardless of whether they are from 4.5.1 or 5.x. Note that versions of the adaptor previous to 4.5.1 (i.e. 4.5 and before) are not compatible.

Q: My application has a page that takes quite some time to return. Eventually, I get an "No Instance Available" message - how do I fix this?
A: You may either use Monitor to increase the read timeout in the adaptor settings to at least the length of time you expect your longest page to take, or use a WOLongResponsePage. Generally, using WOLongResponsePage is the best, as it is more flexible and provides a better user experience.

Q: My application works fine when I have a developer installation, but I can't connect to it when I have a deployment installation.
A: In a deployment install, WODirectConnectEnabled defaults to false, so you won't be able to connect directly -- only through the adaptor. To change this, start your application with -WODirectConnectEnabled true.

Q: While running my application, it eventually freezes. Before it dies, I see the following debugging logs:
<com.webobjects.appserver._private.WODefaultAdaptor>: Growing number of WOWorkerThreads to 32
<com.webobjects.appserver._private.WODefaultAdaptor>: Growing number of WOWorkerThreads to 64
<com.webobjects.appserver._private.WODefaultAdaptor>: Growing number of WOWorkerThreads to 128
<com.webobjects.appserver._private.WODefaultAdaptor>: Growing number of WOWorkerThreads to 256
A: WebObjects grows the number of worker threads as the number of concurrent requests increases. However, if your application doesn't finish processing the request, most likely due to a deadlock, the threads will never finish. Thus, the number of threads grows to the allowed maximum, and then the application appears to "freeze".

Q: I'm pretty sure I have a deadlock. How do I find out where?
A: Bzzt. Still not a deployment question. On MacOS X a quick way to determine whether a deadlock exists is to run your application in Terminal, in the foreground, and when your application deadlocks, press Control-\ .

Q: Help! I can't access the WOStats page!
A: You can set the password (the user is ignored) as an argument: -WOStatisticsPassword myPassword .

Q: What happened to the defaults database?! (defaults write...)
A: WebObjects 5 uses java.util.Properties. The simplest solution is to use use Properties files. A Properties file is a text file named Properties located in the Resources folder of your WOA bundle and/or frameworks. Inside the file are key=value pairs, one to a line.

Q: When I try to run any WebObjects 5.x applications on Windows, I get the following error:
com.webobjects.foundation.NSForwardException [java.io.UnsupportedEncodingException] MacRoman
A: The Windows English JRE does not have all the character encodings. Use the International JRE or the JDK instead.

Q: If I am deploying my application in a JSP/Servlet container, do I need wotaskd, Monitor, or the HTTP adaptors? Do I need to have WebObjects installed on the application server?
A: If you are deploying in a JSP/Servlet container (such as Tomcat or WebLogic), you do not need (and cannot use) wotaskd, Monitor or the HTTP adaptors. However, WebObjects must be installed on the application server.