---

WOJSPServlet

Radar #3038197

Potential performance problem when deploying WebObjects applications on Tomcat 4.0.x, integrating with Apache WebServer using ajp13/WARP protocols.

Description:

In general, WebObjects applications are deployed in Tomcat 4.0.x servlet containers without performance problems. We have tested this either running Tomcat 4.0.x in a standalone mode or integrated with Apache WebServer. There is a particular edge case that you might perceive delay in the response.

1. You are deploying on Tomcat 4.0.x, integrating with Apache WebServer.

2. The connector/protocol that you have chosen for the integration is mod_jk/ajp13 or mod_webapp/WARP (mod_jk/ajp12 doesn't have this edge case problem but it is not recommended in general by Apache. See Apache's website for more details)

3. Your WO application has extremely fast response < 200ms (Usually this means you have little or no database activity). And the content is small, usually smaller than 1500 bytes.

4. You are deploying in a fast LAN.

5. Your Tomcat 4.0.x container runs on Mac OS X.

If all the conditions are satisfied, you will see that your response will take at least 200ms per request-response loop. Here is a short description of the source of the problem for ajp13 protocol.

The way the protocol was designed is that the Tomcat container will respond in 3 chunks: a chunk of short headers, a chunk of body, and a short chunk of end-response content. Because TCP_NODELAY is turned off by default on Mac OS X, chunks do not get sent to the Apache WebServer until either an ack is received or the chunk size is big enough. Tomcat 4.0.x should have turn on TCP_NODELAY when using ajp13 protocol.

Workaround:

There are two options.

1. You can simply ignore this problem since 200ms is not a lot for your users when they are using the browser, especially on the Internet.

2. If you are doing stress testing and you (or your management) are bothered by the 200ms delay, you can patch Tomcat's connectors. Here we describe the patch for ajp13.

• a. You have to get the source codes for Tomcat 4.0.x connectors and try to compile the JAR for tomcat-ajp.jar.

• b. Assuming that you are using the class org.apache.ajp.tomcat4.Ajp13Connector (the default) as your ajp13 connector, you open up org/apache/ajp/Ajp13.java in your favorite editor and search for the method setSocket().

• c. Insert socket.setTcpNoDelay(true) after the setSoLinger() call.

• d. Follow the documentation on compiling the Java side of the ajp13 connector. You can ignore the C side (the Apache part). One of the JARs that you should get is tomcat-ajp.jar.

• e. Copy tomcat-ajp.jar to <TOMCAT_DIR>/server/lib, after you have backed up the original.

Radar #3072947

Some WebObjects applications (particularly JavaClient or DirectToJavaClient) may fail to install as Servlet Single Directory Deployments (SSDD) in WebSphere on Windows.

Description:

Windows has a total file path limit of 255 characters. Normally this is sufficient, however a combination of Project Builder (for MacOSX) frameworks and SSDD can cause some files to exceed this file path limit. The problem is excaerbated by the process of converting symlinks to Windows; because symlinks are flattened, the Project Builder (for MacOSX) build frameworks have an internal structure of /Versions/Current/... as well as Resources and WebServerResources.

Workaround:

In many cases, simply deleting the top level Versions directory in any framework build by Project Builder (for MacOSX) is sufficient. As long as the top level Resources and WebServerResources folders remain, the app should run fine. In some circumstances, the application classpath (in the web.xml) may need to be tweaked if it referenced the framework jar as ...framework/Versions/A/Resources/...

---