Product ReviewFeature-Rich Support for High-Traffic SitesiPlanet Web Server, Enterprise Edition 4.1

• By Kito D. Mann
• July 17, 2000

Version Reviewed: 4.1 Current Version: 4.1
CUP RATING SYSTEM: 5 Outstanding 4 Very Good 3 Acceptable 2 Has Potential 1 Poor

THOSE OF US who have developed servlet and JSP-based solutions constantly hear one question: Do I need to install an external servlet runner? Let's face it—people are more likely to deploy solutions if they don't have to install third-party software. Last year, iPlanet (www.iplanet.com), the Sun–Netscape alliance that develops what used to be Netscape's and Sun's separate server products, released the first version of its popular Web server with solid support for servlets and JSPs.

This year, it released the iPlanet Web Server, Enterprise Edition 4.1 (iWS), boasting support for JSP 1.1, native JVMs (1.2), and the Servlet API 2.2 (minus the WAR files). With all that's going on in the world of servlets and JSP these days, I figured it was time someone took a look at what the folks at Netscape and Sun were doing to support Java at the Web server level. I've worked with all the major servlet engines at one point or another, and I wanted to see if iWS's support was compelling enough to replace veterans in the third-party market such as Allaire's Jrun and eWave's ServletExec (the original developers of these products were both purchased within the last year), and heavyweights such as IBM's WebSphere or BEA's WebLogic.

Installation
I installed the iPlanet Web Server, Enterprise Edition 4.1 (iWS) on two machines: a Micron Millennium 266 MHz Pentium II running Windows NT Workstation 4.0 SP4, and a Dell Inspiron 500 MHz Pentium III laptop with Windows NT Workstation 4.0 SP6. The docs say that iPlanet requires NT 4.0 Service Pack 5, but it seemed to work fine on my desktop. Installation uses a standard InstallShield-style setup program and is pretty straightforward. The Web server ships with Sun's Java Runtime Environment (JRE) 1.2.2, but the setup program allows you to use your own previously installed JDK instead. If you decide to use the default JRE, you can later switch to your own JDK (the JDK is required for JSP support). I installed the default JRE on both machines and later switched to Sun's JDK 1.2.2.

Installation on the older desktop went without a hitch, except that the README shortcut didn't work properly (it made the invalid assumption that my NT directory was on drive C:\). Unfortunately, things didn't go so smoothly on my laptop. Not only was the README shortcut incorrect, but whenever I tried to access the admin server, it couldn't find the "index.lst" file. This is a pretty big deal, since you can't use the admin server's user interface (UI) without it. No one at iPlanet provided a solution, so I just copied two index.lst files from my desktop installation. After I copied the files, the admin server worked fine, with the exception of the context-sensitive help. The installation also includes a shortcut that launches a URL file pointing to your admin server. This works fine for Netscape browsers, but not for Internet Explorer (the admin interface works with either browser).

Once everything was up and running, I noticed that the default home page didn't provide a starting point for local documentation (almost all of the references were to the iPlanet Web site). After poking around a bit, I found a virtual directory called "manual" that points to the directory where the "bookshelf" of documentation is located. This seemed like a lot of effort just to find local documentation.

Documentation and Samples
iWS provides a Programmer's Guide, which serves as a starting point for documentation about all of the different supported technologies, and a Servlet Programmer's Guide, which provides specifics about servlet and JSP support. The Servlet Programmer's Guide is divided into chapters on servlets, JSPs, and examples, with appendices on session management, settings, properties files, JVM configuration, and API clarifications. The last appendix is really useful for gaining an understanding of how iWS implements the Servlet API, which can definitely reduce the number of hours you spend banging your head against the wall, wondering why something doesn't work. The document is basically more of a reference—it won't teach you how to write servlets. It does, however, do a good job of explaining how to install, configure, and debug servlets and JSPs.

The server ships with a number of examples for JSP 0.92, JSP 1.x, and servlets. They are intended to be very simple examples (such as HelloWorld) as opposed to complex applications. Only a few of the samples are mentioned in the documentation, and unfortunately, they aren't installed for you. As a matter of fact, to install them you have to run a shell script, which is fine if you happen to have a copy of the Bourne shell (sh)—which was not the case for my Windows NT 4.0 Work-station installation. It would make a lot more sense for iPlanet to either provide a copy of the shell with the NT distribution, provide the script as a DOS.bat file, or, better yet, ship with the examples preinstalled.

Configuration
The iWS administration interface is completely based on HTML and Java-Script. You can configure most of the server, including servlets and JSPs, through this interface. The admin screen is laid out cleanly with tabs at the tops representing different groups of tasks (such as Global Settings), with the individual pages listed in a frame on the left. The admin server opens with the Administrator Server page, allowing you to globally configure multiple instances of the Web server. From here you can modify global settings, add additional server instances, configure the admin server itself (it is a separate Web server instance), and do cluster management. From the main Administration Server page, you can choose the Web server instance you want to manage (see Figure 1).

Figure 1. The servlet admin page.

I found the admin interface pretty intuitive and quite useful. It was easy to restart the Web server, add servlets, set up virtual paths, and modify JVM parameters. There are, however, a few annoying things about it. Several of the screens accessible from the Servlets tab were a little clunky and inconsistent with similar screens accessible from other tabs. Also, on the Global Servlet Attributes page, you have to type in the names of your start-up servlets. It would make more sense to have a checkbox associated with each servlet entry. In addition, every virtual path (which can be assigned to each servlet) requires a leading forward slash, "/". This is probably a no-brainer for users familiar with iWS and its previous incarnations, but can cause headaches for newbies.

Even though many of the iWS features can be configured through the admin interface, sometimes you still have to work with the configuration files. (The admin server does automatically notice changes to configuration files.) For servlet developers, the best example of this is the context.properties file. While you can change some of the properties through the Global Servlet Attributes page in the admin, you will need to modify the properties file to configure additional global attributes, or to configure attributes for additional contexts. For each context, you can configure the session manager, reload interval, classpath, document root, and several other parameters. What isn't clear from the documentation, how-ever, is how to associate a servlet with a particular context (by default, all servlets use the global context).

Developing With iWS
I decided to use iWS as a development platform for a servlet I wanted to enhance. iWS allows you to specify multiple servlet directories where you can simply place your servlet's class files and access iWS without assigning a name or virtual path. I had my servlet class files placed in their own separate directory, so installing my servlet required two steps: adding the servlet entry (servlet name, class name, initialization arguments, and classpath) and adding a virtual path for the servlet. iWS allows you to specify the classpath at the servlet level, at the context level, and at the JVM level. While you can configure individual JVM attributes at the Web server level, the actual JVM that you choose is global for all Web servers. Since my servlet doesn't use any additional libraries, I only had to specify the classpath at the servlet level. My servlet also requires a virtual directory entry that points to the location of some images it requires. As you might expect, adding a virtual directory was a straightforward process.

Aside from the leading slash issue I mentioned, I didn't have any problems getting my servlet up and running. Somehow, I did manage to create a phantom virtual directory. I did this by creating a servlet virtual directory and a normal virtual directory with the same name and then deleting both entries. After I did this, the virtual directory still worked, even though I couldn't find it listed in the admin UI or in the configuration files. Go figure.

Once I had the servlet up and running, I started making changes and using iWS to view the results. One of iWS's nice features is the ability to modify the reload interval, which determines how long the JVM will work before reloading a modified servlet or JSP. The default value is 5 seconds, which should be adequate for all but the extremely impatient.

The error log, which is accessible through the admin interface, contains information about initialized servlets, the name of the session manager in use, and any exceptions that are thrown. The error log is also where your output from the log() method (in the GenericServlet class) is placed. One thing I couldn't determine initially, however, is where stdout and stderr are sent. As it turns out, the release notes state that they are sent to the stdout and stderr of the Web server process. So, theoretically you could start the Web server script and redirect the output to a file. On NT you can send stdout and stderr to a console window or file by modifying a configuration file manually. Ideally, there should be separate logs for servlet output, and it should be on by default; this is the way most servlet engines are implemented.

Debugging was improved by turning off the just-in-time (JIT) compiler (so that the line numbers in a stack trace will display), which is recommended in the Servlet Programming Guide. However, when I tried turning it off through the admin interface, it didn't work. I had to rename the Symantec JIT DLL in my Java bin directory. The Servlet Programmer's Guide also recommends that the server be in single process mode and that you change some additional JVM properties (manually) before debugging. iWS supports jdb-compatible debuggers as well.

Once I had made some minor modifications to my servlet, I decided to add JSP support. Although iWS uses a native servlet engine, it uses Jasper to compile a JSP into a servlet. Jasper is part of Tomcat, the servlet/JSP reference implementation being developed at the Apache Software Foundation's Jakarta project.

With JSPs, I'm used to getting some type of error displayed in the HTML page when there's a problem with my code (perhaps a friendly message and a stack trace). iWS displays a "Server Error" message when you reference a JSP that has a compile-time error. You have to read the error log (through the admin interface or with a text editor) to see the exception and stack trace.

When it came time to edit the JSP, it didn't seem to recompile properly. I tried this both with my own JSP and with one of the examples, and most of the time, the JSP did not recompile (even with a reload interval of 1 second). The only way I could guarantee a recompile was to delete a "version file." iWS uses version files to determine whether or not to clear out a cache (it keeps caches for JSPs and sessions). Deleting the version file ensures that the next time the server starts, it will clear out the cache. This, however, isn't quite an acceptable solution for recompiling a JSP after you make a change. (A Netscape representative said that this problem would be addressed in Service Pack 1, which should be out by the time this article is published.

Session Management
Once I had worked with JSPs for a while, I took a look at some of the server's other features. One of the unique things about the iPlanet Web Server is that it allows you to use different session managers and also create your own. You can specify a session manager at the servlet, context, and server levels. The two main session managers are the Simple-SessionManager and the MMapSessionManager. The SimpleSessionManager, which is the default, provides basic session support, but when you restart the server, you loose all session data. The MMapSessionManager is a persistent memory map (mmap) session manager that is file-based and works in single- and multiprocess mode. It can also be used to share session information between different Web server instances, which can be on different machines. There is also a third session manager, the JdbcSessionManager, which offers the same features as the MMapSessionManager, except it uses a relational database as the data store. Unfortunately, it is "not written, tested, or intended for production use," according to the Servlet Programmer's Guide.

My servlet uses sessions, so I tried changing the session manager to the MMapSessionManager. Since the admin interface doesn't give you a list of available session managers, it's quite easy to mistype the name (I forgot to use the full package name at first). The problem is that if you mistype the name of the session manager, the Web server won't start (even though the interface will tell you that it did). You have to view the error log to see what the problem is. Once I realized this, everything worked fine.

Security
As you would expect from a leading enterprise Web server, iWS has extensive security support via Access Control Lists (ACLs). ACLs can be used to control any resource, including servlets and JSPs, based on users, groups, and/or host names and IP addresses. This is potentially a very powerful feature, and not every Web server/servlet engine combination supports it.

Performance
Netscape and iPlanet have always emphasized speed. Consequently, iWS provides mechanisms for tuning server performance, and the Servlet Programmer's Guide has specific instructions on how to improve servlet performance. Since iWS allows detailed control over thread management, you can even do things such as "stickyAttach" a server thread to a JVM. That way, a thread remembers it's already attached to the JVM and doesn't have to reconnect. You can also assign a thread pool to a servlet engine. iWS supports custom thread pools that can be assigned to any service. This effectively allows you to limit the number of incoming requests a specific service can handle. All of this is possible because the engineers at iPlanet built the servlet support in process. This increases performance because it avoids communicating to the JVM across process barriers. Some servlet engines, such as WebSphere and Apache JServ, don't support this. (The drawback, of course, is that a buggy JVM could potentially crash the Web server.)

Conclusion
The folks at iPlanet have done an outstanding job of integrating full-fledged servlet and JSP support into their powerful Web server. They've piggybacked on some of iWS's strengths, such as extremely configurable thread management, access control, and clustering. They've focused on speed and integration, but also provide a wealth of configurable features (such as customizable session management, configurable JVMs, and flexible context configuration). There are, however, a few things they could do to make this product worthy of the 5-cup rating. First, the installation could be more reliable. Also, it'd be nice to have the docs and the samples properly configured out of the box. iWS should automatically recompile JSPs without any additional configuration and send stdout and stderr to log files. The UI for the administration server could use some work, but it's definitely useable as-is.

How does it stack up to the competition? As far as basic servlet support and JSP support is concerned, it's definitely a solid product, and could easily eliminate the need for a third-party servlet runner. If you're using an application server such as WebSphere or WebLogic, you will need to weigh the level of integration in their servlet engines against the speed and flexibility that iWS offers.

I'm not convinced that iPlanet Web Server, Enterprise Edition 4.1 is currently an ideal platform for developing servlets. However, I think it's an excellent deployment platform and is capable of providing servlet and JSP support for high-volume, high-profile sites.

Review in a Nutshell

Product Description: A full-fledged, feature-rich Web server designed for "high traffic, complex" Web sites. Has complete support for the Servlet API 2.2 (minus WAR files) and JSP 0.92 and 1.x. Pros: Fully integrated servlet and JSP support. Fast servlet and JSP execution. Flexible session management. Flexible thread management. Integrated access control. Integrated support for OptomizeIt profiler tool. Cons: Doesn't write stdout and stderr to separate log files. Has trouble recompiling modified JSPs. Samples not easy to install under NT. Unreliable installation on NT. Bottom Line: As far as basic servlet and JSP support is concerned, it's definitely a solid product. I'm not convinced that iPlanet Web Server, Enterprise Edition 4.1 is an ideal platform for developing servlets. However, I think it's an excellent deployment platform and is capable of providing world-class servlet and JSP support for high-volume, high-profile sites. System Requirements: Windows NT 4.0 Service Pack 5. JDK 1.2.2 or higher (for JSP support). 64 MB RAM (more recommended for serving high volumes; an additional 16 MB is required for each additional server instance). Paging space at least as large as the amount of RAM on your system (more is recommended). 100 MB of free disk space for installation. 30 MB of free disk space for log files. Netscape Communicator 4.61 or higher, or Microsoft Internet Explorer 4.01 or higher. Price: $1,495.00