Programmer's Guide to Servlets

Table of Contents | Previous | Next | Index | Bookshelf

Programmer's Guide to Servlets

Chapter 1. Using Servlets and JavaServer Pages

iPlanet Web Server 4.1 supports servlets and JavaServer Pages (JSP). This chapter gives a brief overview of servlets and JSPs and discusses how to enable and configure them in iPlanet Web Server 4.1.

The sections in this chapter are:

Servlets

Java servlets are server-side Java programs that web servers can run to generate content in response to a client request in much the same way as CGI programs do. Servlets can be thought of as applets that run on the server side without a user interface. Servlets are invoked through URL invocation.

iPlanet Web Server 4.1 includes support for JavaSoft's Servlet API at the level of the 2.2.1 specification.

NOTE: Servlet API version 2.2.1 is fully backward compatible with version 2.1, so all existing servlets will continue to work without modification or recompilation.

To develop servlets, use Sun Microsystems' Java Servlet API. For information about using the Java Servlet API, see the documentation provided by Sun Microsystems at:

http://java.sun.com/products/servlet/index.html

iPlanet Web Server 4.1 includes all the files necessary for developing Java Servlets. The servlets.jar file is in the iPlanet Web Server 4.1 installation directory at:

server_root/bin/https/jar

When compiling servlets, make sure the servlets.jar file is accessible to your Java compiler. Include the servlets.jar file in your CLASSPATH.

iPlanet Web Server 4.1 supports the <SERVLET> tag as introduced by Java Web Server. This tag allows you to embed servlet output in an HTML file. No configuration changes are necessary to enable this behavior. If SSI and servlets are both enabled, the <SERVLET> tag is enabled.

The <SERVLET> tag syntax is slightly different from that of other SSI commands; it resembles the <APPLET> tag syntax:

<servlet name=name code=classfile codebase=path iParam1=v1 iParam2=v2>

<param name=param1 value=v3>

<param name=param2 value=v4>

</servlet>

The code parameter, which specifies the .class file for the servlet, is always required. The .class extension is optional. The codebase parameter is required if the servlet is not defined in the servlets.properties file and the .class file is not in the same directory as the HTML file containing the <SERVLET> tag. The name parameter is required if the servlet is defined in the servlets.properties file, and must match the servlet name defined in that file.

For more information about the servlets.properties file, see Appendix C, "Properties Files." For more information about SSI commands, see the Programmer's Guide for iPlanet Web Server.

JavaServer Pages

iPlanet Web Server 4.1 supports JavaServer Pages (JSP) to the level of JSP API 1.1 compliance.

NOTE: JSP API version 1.x is not backward compatible with JSP API version 0.92. To run version 0.92 JSPs, you must create legacy directories for them as described in the section "Running 0.92 JSP."

A JSP is a page, much like an HTML page, that can be viewed in a web browser. However, as well as containing HTML tags, it can include a set of JSP tags that extend the ability of the web page designer to incorporate dynamic content in a page. These tags provide functionality such as displaying property values and using simple conditionals.

One of the main benefits of JSPs is that, like HTML pages, they do not need to be compiled. The web page designer simply writes a page that uses HTML and JSP tags and puts it on their web server. The web page designer does not need to learn how to define Java classes or use Java compilers.

JSP pages can access full Java functionality in the following ways:

by embedding Java code directly in scriptlets in the page
by accessing Java beans
by using server-side tags that include Java servlets

Both beans and servlets are Java classes that need to be compiled, but they can be defined and compiled by a Java programmer, who then publishes the interface to the bean or the servlet. The web page designer can access a pre-compiled bean or servlet from a JSP page.

For information about creating JSPs, see Sun Microsystem's JavaServer Pages web site at:

http://java.sun.com/products/jsp/index.html

For information about Java Beans, see Sun Microsystem's JavaBeans web page at:

http://java.sun.com/beans/index.html

What Does the Server Need to Run Servlets and JSP?

iPlanet Web Server 4.1 includes the Java Runtime Environment (JRE) but not the Java Development Kit (JDK) due to licensing restrictions. The server can run servlets using the JRE, but it needs the JDK to run JSP.

iPlanet Web Server 4.1 requires you to use the following recommended versions of JRE/JDK or later versions, with different platforms requiring different versions, as summarized in Table 1.1.

Table 1.1 Supported JRE/JDK Versions by Platform

Platform JRE/JDK Version
Solaris Sparc
1.2.2_01

Windows NT
1.2.2_01

HPUX
1.2.2_02

AIX
1.2.1

DEC
1.2.1-2

Linux
1.2.2RC3+

IRIX
1.2.1

Platform	JRE/JDK Version
Solaris Sparc	1.2.2_01
Windows NT	1.2.2_01
HPUX	1.2.2_02
AIX	1.2.1
DEC	1.2.1-2
Linux	1.2.2RC3+
IRIX	1.2.1

Check the iPlanet Web Server Installation and Migration Guide and the latest release notes for updates on required JDK versions.

NOTE: On Sun Solaris, the JRE included is the JRE 1.2.2 reference implementation from JavaSoft. For better performance, use the latest SunSoft production release of JDK.

JDK 1.2 (and other JDK versions) are available from Sun Microsystems at:

http://java.sun.com/products/jdk/1.2/

You can specify the path to the JDK in either of the following ways:

You can specify the path during the server installation process.

When you install iPlanet Web Server 4.1, one of the dialog boxes in the installation process asks if you want to use a custom Java Development Kit (JDK), and if so, you can specify the path to it.

You can specify it after the server is installed.

To specify the path to the JDK, switch to the Web Server Administration Server, select the Global Settings tab, and use the Configure JRE/JDK Paths page, as discussed in the section "Configuring JRE/JDK Paths." Whether you specify the path to the JDK during installation or later, the path is the directory in which you installed the JDK.

Serving Servlets and JSP

iPlanet Web Server 4.1 includes an appropriate version of the Java runtime environment (JRE) for running servlets. For the server to be able to serve JSP, you must specify a path to a Java Development Kit (JDK) as discussed in the section "What Does the Server Need to Run Servlets and JSP?."

For the server to serve servlets and JSP, servlet activation must be enabled. (See the section "Activating Servlets and JSP" for details.)

When servlets are enabled, you have a choice of two ways to make a servlet accessible to clients:

Put the servlet class file in one of the directories that has been registered with the iPlanet Web Server as a servlet directory. For more information, see "Registering Servlet Directories."

Define a servlet virtual path for the servlet. In this case, the servlet class can be located anywhere in the file system or even reside on a remote machine. For more information, see "Specifying Servlet Virtual Paths."

No special steps are needed to enable JSP pages other than making sure that JSP is enabled on the iPlanet Web Server. So long as JSP is enabled, the iPlanet Web Server treats all files with a .jsp extension as JSPs. (Do not put JSP files in a registered servlet directory, since the iPlanet Web Server expects all files in a registered servlet directory to be servlets.) An exception is a JSP page written to the 0.92 spec, which must be placed in a legacy directory; see the section "Running 0.92 JSP" for details.

In detail, to enable the iPlanet Web Server to serve servlets and JSP pages, do the following steps:

Activating Servlets and JSP (this is the only step needed to enable JSP)

Configuring Global Servlet Attributes

Registering Servlet Directories

Registering Individual Servlets if Needed

Specifying Servlet Virtual Paths if Desired

Configuring JVM if Necessary

Using the Server Manager Interface

For information about using the Server Manager interface to specify settings for servlets, see the following topics in the online help. All these pages are located on the Servlets tab.

The Enable/Disable Servlets/JSP Page
The Servlet Directory Page
The Legacy JSP Directory Page
The Configure Global Servlet Attributes Page
The Configure Servlet Attributes Page
The Configure Servlet Virtual Path Translation Page
The Configure JVM Attributes Page
The Delete Version Files Page

In addition, the Configure JRE/JDK Paths page on the Global Settings tab in the Web Server Administration Server allows you to specify paths to the JRE and JDK.

Activating Servlets and JSP

To enable and disable servlets and JSP in iPlanet Web Server 4.1, use the Servlets>Enable/Disable Servlets/JSP page in the Server Manager interface.

You must enable both servlets and JSP to run JSP. Even if servlets are enabled, JSP can still be disabled. However, if you disable servlets, JSP is automatically also disabled. In this case, if you enable servlets later, you will need to re-enable JSP also if desired.

You can also define a thread pool to be used for servlets. For more information about thread pools, see "Maximizing Servlet Performance" and "Adding and Using Thread Pools" in Chapter 7, "Configuring Server Preferences," in the iPlanet Web Server Administrator's Guide.

To enable servlets programmatically, add the following lines to obj.conf. These directives first load the shared library containing the servlet engine, which is in server_root/bin/https/bin/NSServletPlugin.dll on Windows NT or server_root/bin/https/lib/libNSServletPlugin.so on Unix. Then they initialize the servlet engine.

Init fn="load-modules" shlib="server_root/bin/https/bin/NSServletPlugin.dll" funcs="NSServletEarlyInit,NSServletLateInit,NSServletNameTrans,NSServletService" shlib_flags="(global|now)"

Init fn="NSServletEarlyInit" EarlyInit="yes"

Init fn="NSServletLateInit" LateInit="yes"

In the default object in obj.conf, add the following NameTrans directive:

NameTrans fn="NSServletNameTrans" name="servlet"

By default, regardless of whether servlets are enabled or disabled, the file obj.conf contains additional objects with names such as servlet, jsp, and ServletByExt. Do not delete these objects. If you delete them, you can no longer activate servlets through the Server Manager.

A JSP page written to the 0.92 spec must be placed in a legacy directory; see the section "Running 0.92 JSP" for details.

Configuring Global Servlet Attributes

You can specify the following optional servlet attributes:

Startup Servlets -- servlets to be loaded when the iPlanet Web Server starts up.

Session Manager -- the session manager for servlets. For more information about the session manager, see Appendix A, "Session Managers."

Session Manager Args -- the session manager arguments for the servlet engine. For more information about the session manager, see Appendix A, "Session Managers."

Reload Interval -- the time period that the server waits before re-loading servlets and JSPs if they have changed on the server. The default value is 5 seconds.

You can set these attributes interactively in the Servlets>Configure Global Servlet Attributes page in the Server Manager interface. Alternatively, you can edit the configuration file servlets.properties in the server's config directory.

The following code shows an example of the settings in servlets.properties:

# General properties:
servlets.startup=hello 
servlets.config.reloadInterval=5 
servlets.config.docRoot=C:/Netscape/Server4/docs 
servlets.sessionmgr=com.netscape.server.http.session.SimpleSessionManager

Registering Servlet Directories

One of the ways to make a servlet accessible to clients is to put it into a directory that is registered with the iPlanet Web Server as a servlet directory. Servlets in registered servlet directories are dynamically loaded when needed. The server monitors the servlet files and automatically reloads them on the fly as they change.

You can register any number of servlet directories for the iPlanet Web Server. Initially, the iPlanet Web Server has a single servlet directory, which is server_root/docs/servlet/.

For example, if the SimpleServlet.class servlet is in the servlet subdirectory of the server's document root directory (the default servlet directory), you can invoke the servlet by pointing the web browser to:

http://your_server/servlet/SimpleServlet

The iPlanet Web Server expects all files in a registered servlet directory to be servlets. The server treats any files in that directory that have the .class extension as servlets. The iPlanet Web Server does not correctly serve other files, such as HTML files or JSPs, that reside in that directory.

The server can have multiple servlet directories. You can map servlet directories to virtual directories if desired. For example, you could specify that http://poppy.my_domain.com/products/ invokes servlets in the directory server_root/docs/january/products/servlets/.

To register servlet directories and to specify their URL prefixes, use the Servlets>Servlet Directory page in the interface.

Alternatively, you can register servlet directories by adding appropriate NameTrans directives to the default object in the file obj.conf, such as:

NameTrans fn="pfx2dir" from="/products" dir="d:/netscape/server4/docs/january/products/servlets/" name="ServletByExt"

You can invoke a servlet in a subdirectory of a registered servlet directory if you include a package directive in the servlet code that corresponds to the path from the registered servlet directory. For example, suppose the servlet is in the following location, and that server_root/docs/servlet/ is a registered servlet directory:

server_root/docs/servlet/HelloWorld/HelloWorldServlet.class

Include the following package directive as the first line in the Java source file:

package HelloWorld;

You can then invoke the servlet by pointing the web browser to:

http://your_server/servlet/HelloWorld.HelloWorldServlet

Registering Individual Servlets

The iPlanet Web Server treats any file in a registered servlet directory as a servlet. There is no need to register individual servlets that reside in these directories unless any of the following criteria apply:

The servlet takes input parameters that are not passed through the request URL.
You want to set up additional virtual URLs for the servlet.
Your servlets are packaged or in a .jar file. The server does not search .class or .jar files for packaged servlets.

If any of these conditions is true, register the individual servlet by using the Servlets>Configure Servlet Attributes page in the Server Manager interface. Alternatively, you can edit the file servlets.properties to add an entry for the servlet.

When registering an individual servlet, specify the following attributes:

Servlet Name -- The iPlanet Web Server uses this value as a servlet identifier to internally identify the servlet. (This identifier is not part of the URL that is used to invoke the servlet, unless by coincidence the identifier is the same as the class code name.)

Servlet Code (class name) -- the name of the class file. You do not need to specify the .class extension.

Servlet Classpath -- This is the absolute pathname or URL to the directory or zip/jar file containing the servlet. The classpath can point anywhere in the file system. The servlet classpath may contain a directory, a .jar or .zip file, or a URL to a directory. (You cannot specify a URL as a classpath for a zip or jar file.)

If the servlet classpath is not a registered servlet directory, you must additionally provide a servlet virtual path for it (as discussed in

"Specifying Servlet Virtual Paths"

iPlanet Web Server supports the specification of multiple directories, jars, zips, and URLs in the servlet classpath.

Servlet Args -- a comma delimited list of additional arguments for the servlet if required.

For example, in Figure 1.1, the Servlets>Configure Servlet Attributes page of the Server Manager interface shows configuration information for a servlet whose class file buynow1A resides in the directory D:/Netscape/server4/docs/servlet/buy. This servlet is configured under the name BuyNowServlet. It takes additional arguments of arg1=45, arg2=online, arg3="quick shopping".

Figure 1.1 Configuring attributes for an individual servlet

The following code shows an example of the configuration information for the same servlet in servlets.properties:

servlet.BuyNowServlet.classpath=D:/Netscape/server4/docs/servlet/buy;D:/Netscape/server4/docs/myclasses
servlet.BuyNowServlet.code=BuyNow1A
servlet.BuyNowServlet.initArgs=arg1=45,arg2=online,arg3="quick shopping"

Note that you can specify multiple values as the servlet classpath if needed.

Specifying Servlet Virtual Paths

If you register a servlet individually instead of putting it in a servlet directory, you must define a servlet virtual path for it. For example, you could specify that the URL

http://poppy.my_domain.com/plans/plan1

invokes the servlet defined in the directory

server_root/docs/plans/releaseA/planP2Version1A.class

You can set up servlet virtual paths for servlets that reside anywhere in the file system, in or out of a registered servlet directory.

To specify a servlet virtual path, use the Servlets>Configure Servlet Virtual Path Translation page in the Server Manager interface. In this page, specify the virtual path name and the servlet name. You can alternatively manually edit the rules.properties configuration file to add a servlet virtual path. Only servlets for which a virtual path has been set up can use initial arguments (See "GenericServlet.getInitParameter and getInitParameterNames" for information about initial arguments.)

Before using a servlet virtual path, a servlet identifier (or servlet name) must be added for the servlet in the Servlets>Configure Servlet Attributes page of the interface (or in the servlets.properties configuration file).

Virtual Servlet Path Example

This example shows how to specify that the logical URL

http://poppy.my_domain.com/plans/plan1

invokes the servlet defined in

server_root/docs/plans/releaseA/planP2Version1A.class.

1. Specify the servlet identifier, class file, and class path.

In the Servlets>Configure Servlet Attributes page in the interface, do the following:

In the Servlet Name field, enter an identifier for the servlet, such as plan1A. (Notice that this is not necessarily the same as the class file name).

In the Servlet Code field, enter the name of the class file, which is planP2Version1A. Don't specify any directories. The .class extension is not required.

In the Servlet Classpath field, enter the absolute path name for the directory, jar or zip file where the servlet class file resides, or enter a URL for a directory. In this example, you would enter server_root/docs/servlet/plans/releaseA. (For example: D:/netscape/server4/docs/servlet/plans/releaseA.)

In the Servlet Args field, enter the additional arguments that the servlet needs, if any. (This example does not use extra arguments.)

Figure 1.2 shows the settings in the interface.

Save the changes.

Figure 1.2 Specifying the servlet name, code, and class path

To make this change programmatically, add the following lines to the configuration file servlets.properties:

servlet.plan1A.classpath=D:/Netscape/server4/docs/servlet/plans/releaseA/

servlet.plan1A.code=planP2Version1A

2. Specify the virtual path for the servlet.

In the Servlets>Configure Servlet Virtual Path Translations page, do the following:

In the Virtual Path field, enter the virtual path name. Note that the server name is implied as a prefix, so in this case you would only need to enter
/plans/plan1 to specify the virtual path http://poppy.mcom.com/plans/plan1.

In the Servlet field, enter the identifier for the servlet that is invoked by this virtual path. This is the servlet identifier that you specified in the Configure Servlet Attributes page, which in this case is plan1A.

Save the changes.

Figure 1.3 shows the settings in the interface.

Figure 1.3 Adding a virtual path

To do this programmatically, add the following line to rules.properties:

/plans/plan1=plan1A

After this virtual servlet path has been established, if a client sends a request to the server for the URL http://poppy.my_domain.com/plans/plan1, the server sends back the results of invoking the servlet in server_root/docs/servlet/plans/releaseA/plan2PVersion1A.class.

Specifying Servlet Contexts

Contexts allow multiple servlets to exchange data and access each other's fields. Contexts are useful for defining virtual servers or for code isolation. You define contexts in the servlets.properties and contexts.properties files. For more information, see Appendix C, "Properties Files."

Configuring JRE/JDK Paths

When you install iPlanet Web Server 4.1, you can choose to install the Java Runtime Environment (JRE) that is shipped with the server, or you can specify a path to your own JRE or the Java Development Kit (JDK).

The server can run servlets using the JRE, but it needs the JDK to run JSP. The JDK is not bundled with the iPlanet Web Server, but you can download it for free from Sun Microsystems at:

http://java.sun.com/products/jdk/1.2/

iPlanet Web Server 4.1 requires you to use version of the JDK listed in the section "What Does the Server Need to Run Servlets and JSP?"

Regardless of whether you choose to install the JRE or specify a path to the JDK during installation, you can tell the iPlanet Web Server to switch to using either the JRE or JDK at any time. Switch to the Web Server Administration Server, select the Global Settings tab, and use the Configure JRE/JDK Paths page. You can also change the path to the JDK in this page.

On the Configure JRE/JDK Paths page, supply values for the following fields if you select the JDK radio button:

JDK Path

Enter the path for the JDK. This is the directory where you installed the JDK.

JDK Runtime Libpath

Enter the runtime library path for the JDK.

JDK Runtime Classpath

The class path includes the paths to the directories and jar files needed to run the servlet engine, the servlet examples, and any other paths needed by servlets that you add. You can add new values to the existing class path, but don't delete the existing value since it includes paths that are essential for servlet operation.

Supply values for the following fields if you select the JRE radio button:

JRE Path

Enter the path for the JRE. This is the directory where you installed the JRE.

JRE Runtime Libpath

Enter the runtime library path for the JRE.

NOTE: If you are not sure of the JDK runtime libpath, the JDK runtime classpath, or the JRE runtime libpath, leave these fields blank to tell the server to use the default paths.

It is easiest to use the Configure JRE/JDK Paths page to switch between the JRE and the JDK, but you can also make the change programmatically, as follows:

On Unix:

Edit the file server_root/https-admserv/start-jvm.

If the server is currently using the JRE, this file has a variable NSES_JRE. To enable the server to use a JDK, add the variable NSES_JDK whose value is the JDK directory. You'll also need to change the value of the NSES_JRE variable.

NSES_JDK should point to the installation directory for the JDK, while NSES_JRE should point to the JRE directory in the installation directory for JDK (that is, jdk_dir/jre).

On Windows NT:

Add the path to the Java libraries to the extrapath setting in magnus.conf.

Edit the NSES_JDK and NSES_JRE variables in the registry HKEY_LOCAL_MACHINE/SOFTWARE/Netscape/Enterprise/4.0/. If the server is enabled to use the JDK, both these variables are needed. If the server is to use the JRE, only the NSES_JRE variable should be set.

NSES_JDK should point to the installation directory for the JDK, while NSES_JRE should point to the JRE directory in the installation directory for JDK (that is, jdk_dir/jre).

NOTE: To activate changes to the JRE/JDK paths, you must restart the server from the On/Off option on the Preferences tab.

Deleting Version Files

The server uses two directories to cache information for JavaServer Pages (JSP) and servlets:

ClassCache

When the server serves a JSP page, it creates a .java and a .class file associated with the JSP and stores them in the JSP class cache under the ClassCache directory.

SessionData

If the server uses the MMapSessionManager session manager, it stores persistent session information in the SessionData directory. (For more information about session managers, see

Appendix A, "Session Managers."

Each cache has a version file containing a version number that the server uses to determine the structure of the directories and files in the caches. You can clean out the caches by simply deleting the version file.

When the server starts up, if it does not find the version files, it deletes the directory structures for the corresponding caches and re-creates the version files. Next time the server serves a JSP page, it recreates the JSP class cache. The next time the server serves a JSP page or servlet while using MMapSessionManager session manager, it recreates the session data cache.

If a future upgrade of the server uses a different format for the caches, the server will check the number in the version file and clean up the caches if the version number is not correct.

You can delete the version files simply by deleting them from the ClassCache or SessionData directories as you would normally delete a file, or you can use the Servlets>Delete Version Files page in the Server Manager to delete them. After deleting one or both version files, be sure to restart the iPlanet Web Server to force it to clean up the appropriate caches and to recreate the version files before the server serves any servlets or JSPs.

Configuring JVM

If necessary, you can configure parameters for JVM either by using the Servlets>Configure JVM Attributes page in the Server Manager interface, or by editing jvm12.conf.

The default settings in iPlanet Web Server for JVM are suitable for running servlets. However, there may be times when you want to change the settings. For example, if a servlet or bean file uses a JAR file, add the JAR location to the Classpath variable. To enable the use of a remote profiler, set the OPTITDIR and Profiler variables.

NOTE: A few attributes on the Configure JVM Attributes page on the Servlets tab show as "Default." Since you can use different JVMs, these default values are unknown. You cannot query a JVM to find out the actual default values; instead, refer to your JVM documentation. For example, for Sun's JVM, if you choose Yes for the JIT Compiler option, it shows as "Default" because JIT is enabled in the JVM by default. However, if you choose No for the JIT compiler, an explicit entry, jvm.compiler=NONE, is added to the jvm12.conf file.

The JVM parameters you can set are:

Option -- You can set any options allowed by the vendor's JVM.

Profiler -- If you are using the Optimizeit! 3.0 profiler from Intuitive Systems, enter the value optimizeit. For more information about this optimizer, see Appendix F, "Remote Servlet Profiling."

OPTITDIR -- If you are using the Optimizeit! 3.0 profiler from Intuitive Systems, enter the pathname for the directory where Optimizeit! resides, for example, D:/App/IntuitiveSystems/OptimizeIt30D. For more information about this optimizer, see Appendix F, "Remote Servlet Profiling."

Minimum Heap Size -- determines the minimum heap size allocated for Java.

Maximum Heap Size -- determines the maximum heap size allocated to Java.

Compiler -- You can specify options to turn on and off JIT (just-in-time compiler). See your JVM documentation for details.

Classpath -- Enter additional classpath values as needed. For example, if a JSP uses a bean that is packaged in a JAR, add the JAR path to the classpath.

The classpath must not include backslashes in directory names. If you use backslashes in the directory path when using the Web Server Administrative Server interface, the system automatically converts the backslashes to forward slashes. However, if you edit the jvm12.conf file, do not use backslashes in directory names.

Enable Class GC -- Specifies whether or not to enable class garbage collection. The default is yes.

Verbose Mode -- Determines whether the JVM logs a commentary on what it is doing, such as loading classes. The commentary appears in the error log.

Enable Debug -- You can enable or disable remote debugging. The default is disabled. For more information about remote debugging, see Appendix E, "Debugging Servlets and JSPs."

Running 0.92 JSP

JSP API version 1.x is not backward compatible with version 0.92. However, the iPlanet Web Server correctly serves JSPs written to the 0.92 spec if you place them in JSP legacy directories. If a 0.92 JSP does not reside in a JSP legacy directory, it will not work.

The Legacy JSP Directory page in the Servlets tab of the Server Manager allows you to add legacy JSP directories. For information about how to use this page, see the Legacy JSP Directory page in the online help.

JSP legacy directories can contain JSPs and other files such as HTML pages.

Maximizing Servlet Performance

Consider the following guidelines for improving servlet performance:

Use Sun's JVM on Solaris--it's up to 50% faster than JavaSoft's.

If you edit your obj.conf file manually, make sure that the servlet NameTrans (NameTrans fn="NSServletNameTrans" name="servlet") is always the first NameTrans directive.

This directive uses a highly optimized URI cache for loaded servlets and returns REQ_PROCEED if the match is found, thus eliminating the need of other NameTrans directives to be executed.

Servlets defined individually (via the Configure Servlet Attributes page or rules.properties and servlets.properties) are slightly faster than dynamically loaded servlets (in servlet directories).

The jvm12.conf file has a configuration parameter, jvm.stickyAttach. Setting the value of this parameter to 1 causes threads to remember that they are attached to the JVM, thus speeding up request processing by eliminating AttachCurrentThread and DetachCurrentThread calls. It can, however, have a side-effect: recycled threads which may be doing other processing can be suspended by the garbage collector arbitrarily.

Thread pools can be used to eliminate this side effect for other subsystems. For more information about thread pools, see "Adding and Using Thread Pools" in Chapter 7, "Configuring Server Preferences," in the iPlanet Web Server Administrator's Guide.

Increase the front-end thread stack size in magnus.conf (via the StackSize variable), or the respective pool stack size parameter if you're using thread pools. For more information, see the NSAPI Programmer's Guide for iPlanet Web Server.

Increase the heap size to help garbage collection: jvm.minHeapSize or maxHeapSize or the Configure JVM Attributes page.

Ensure that your classpath is short: jvm.classpath (if you don't need some of the examples). You can set jvm.include.CLASSPATH=1, so it won't inherit the CLASSPATH environment variable.

Sometimes, iPlanet Web Server 4.1 may run out of stack space if applications use deep recursion when a JIT compiler is enabled, especially on UNIX platforms where the default stack size is small, or in any cases where very complex JSP pages are used.

You can set the stack space using the StackSize parameter in the magnus.conf file. For more information, see the NSAPI Programmer's Guide for iPlanet Web Server.

The use of the NSAPI cache improves servlet performance in cases where the obj.conf configuration file has many directives. To enable the NSAPI cache, include the following line in obj.conf:

      Init fn="nsapi-cache-init" enable=true

The session ID generator, which is used for servlet sessions, employs cryptographically strong unique random number generation algorithms. This may present a performance problem on older, slow machines. For more information, see Appendix A, "Session Managers."

Table of Contents | Previous | Next | Index

Last Updated: 02/25/00 16:19:08