Monday Jan 26, 2009

Web Server Internals

A couple of weeks ago, Sun open sourced a lot of the code in Sun Java System Web Server 7.0. Having worked on the product for a number of years, I'm happy to see the code out in open source. One of the reasons for releasing the code under the BSD license was to evangelize the technology to any other open source projects/communities that might be interested in it.

While the source code is available for browsing at http://src.opensolaris.org/source/xref//webstack/webserver/ I suspect that most of you don't have the time to dig through all that code to find the bits that may be of interest to you! What I propose to spend some time doing over the next few weeks is to take features of the Web Server implementation that I think are interesting/innovative and write up some technical documentation (annotated with source code references) that explain how the feature is implemented in Web Server.

I propose to start by blogging about the following sub-systems in Web Server:

  • Configuration Management - How Web Server seamlessly installs configuration changes without having to restart the server process
  • Connection Management - The internals of Web Server's massively scalable connection-handling subsystem

If there are other areas that you would like information about, please let me know.


Wednesday Jul 25, 2007

Can I use Struts with Web Server 7?

When I was asked whether one could use the Apache Struts framework with Sun Java System Web Server 7, I was sure I would find an answer (confirming that one indeed could) if I searched the Internet. I was somewhat surprised and disappointed when I didn't any evidence either supporting or disproving the theory, so I decided to try it out myself.

I downloaded and unzipped the samples for both Struts 1(struts-1.3.8-apps.zip) and Struts 2(struts-2.0.9-apps.zip) from http://struts.apache.org/download.cgi. I then started the administration server of my Web Server 7 installation and deployed a few of the sample web applications to my test server.

Sample web application URI
struts-1.3.8/apps/struts-blank-1.3.8.war /blank1
struts-1.3.8/apps/struts-cookbook-1.3.8.war /cookbook1
struts-1.3.8/apps/struts-examples-1.3.8.war /examples1
struts-2.0.9/apps/struts2-blank-2.0.9.war /blank2
struts-2.0.9/apps/struts2-showcase-2.0.9.war /showcase2

I started my server after deploying the above samples. If your server is already running you don't have to restart the server when you deploy web applications(the server can dynamically reload Java web applications).

% bin/startserv
Sun Java System Web Server 7.0U1 B07/13/2007 16:10
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_12] from [Sun Microsystems Inc.]
info: WEB0100: Loading web module in virtual server [test] at [/blank1]
info: WEB0100: Loading web module in virtual server [test] at [/cookbook1]
info: WEB0100: Loading web module in virtual server [test] at [/examples1]
info: WEB0100: Loading web module in virtual server [test] at [/blank2]
info: WEB0100: Loading web module in virtual server [test] at [/showcase2]
(rest of output deleted)

All the samples worked! All I did was simply deploy the .war files to Web Server 7. Cool!

So, can Struts can be used with Sun Java System Web Server 7? Yes! Yes! Yes!

Monday May 21, 2007

Smart Reloading of Java Web Applications in Web Server 7.0

One of the cool new features in Sun Java System Web Server 7 is its ability to detect and dynamically reload (without having to restart the server) web applications that have changed. During web application development, it becomes very tedious and time consuming if one has to restart the server to test every change made. Requiring a server restart also prevents the ability to do web application development on a shared server without disruption to the other users of the server.

The ability to dynamically reconfigure many of the our web server's settings (including web applications) without having to restart the server was first introduced in iPlanet Web Server 6.0 and this feature was improved upon in the Sun ONE Web Server 6.1 release. Although both Web Server 6.0 and 6.1 didn't require that you restart the server to reload a web application, they did implicitly reload all web applications when the server was dynamically reconfigured. While this brute force approach to dynamically reloading web applications wasn't quite as expensive as restarting the server, it - i.e. dynamically reconfiguring the server - did have a few undesirable and unexpected side-effects namely,

  • each web application was reloaded even if it hadn't changed
  • all in-memory web application session data was lost
  • one had to wait until all web applications had been reloaded in order to test any change made to a single web application

Web Server 7 has addressed all of the above limitations of the previous releases. Web Server 7 can intelligently detect which of the web applications have changed and only reload those that have. You can also deploy and undeploy web applications without restarting the server.

For example, if you have a Web Server 7 instance with 2 web applications deployed at /foo and /bar respectively, when you start the server you will see something similar to the following:

% bin/startserv
Sun Java System Web Server 7.0U1 B05/07/2007 00:21
info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.]
info: WEB0100: Loading web module in virtual server [server] at [/foo]
info: WEB0100: Loading web module in virtual server [server] at [/bar]
info: HTTP3072: http-listener-1: http://server:7080 ready to accept requests
info: CORE3274: successful server startup

If you reconfigure the instance without modifying either of the web applications, you will notice that the server does not reload either web application.

% bin/reconfig
info ( 1170): CORE3276: Installing a new configuration
info ( 1170): CORE3280: A new configuration was successfully installed

If you modify one of the web applications and reconfigure the instance, the server correctly reloads only the web application that was modified.

% touch web-app/foo/WEB-INF/web.xml 
% bin/reconfig
info ( 1170): CORE3276: Installing a new configuration
info ( 1170): WEB0100: Loading web module in virtual server [server] at [/foo]
info ( 1170): CORE3280: A new configuration was successfully installed

By only reloading those web applications that have changed, in-memory session data for the other web applications is preserved across dynamic reconfigurations and the time taken to complete a dynamic reconfiguration is also less than was the case in previous releases of the web server.

You can dynamically reload a web application (that is deployed on a running Web Server 7 instance) without restarting the server when

  • you make changes to any servlets in the application (changes to JSPs do not require that the web application be reloaded)
  • you make changes to the web application deployment descriptors i.e. WEB-INF/web.xml, WEB-INF/sun-web.xml
  • you make changes to the <servlet-container> settings in instance_dir/config/server.xml
  • you make changes to the global web deployment descriptor instance_dir/config/default-web.xml

When you make a change that affects all web applications, the server detects this and reloads all the applications when the instance is reconfigured. For example, if you change the global web deployment descriptor that is common to all web applications and reconfigure the server you will see that the server reloads all the web applications.

% touch config/default-web.xml
% bin/reconfig
info ( 1170): CORE3276: Installing a new configuration
info ( 1170): WEB0100: Loading web module in virtual server [server] at [/foo]
info ( 1170): WEB0100: Loading web module in virtual server [server] at [/bar]
info ( 1170): CORE3280: A new configuration was successfully installed

Changes to the following settings require that you restart the server

A web application deployed on Web Server 7 can be dynamically reloaded either by executing a command or at specific intervals or as per a specific schedule. You do not have to specify which web applications have been modified, the server automatically detects this.

Reload-on-demand: After making changes to the web application(s), you reconfigure the instance. Reconfiguring the instance instantly loads all the changes made to any/all web application(s). You can reconfigure the instance either from the Administration Graphical User Interface or by running instance_dir/bin/reconfig or by using the wadm reconfig-instance command.

Reload-at-intervals:Enable dynamic reloading of web applications. The dynamic reload interval that you specify determines that interval (in seconds) at which the web applications are checked for modifications and reloaded if necessary.

Reload-by-schedule: Schedule an event to reconfigure the instance. When the event is executed at the scheduled time/interval, the deployed web applications are checked for modifications and reloaded if necessary.

Thus, you can see that you have flexibility in configuring when your web applications should be checked for modifications and reloaded if necessary. I hope you find that the new and improved dynamic reloading feature of Sun Java System Web Server 7 improves your productivity as a developer and deployer of Java content. Please let me know if you have any feedback about this feature.

Tuesday May 16, 2006

Web Server 7: Type Less, Do More from the Command Line

The Sun Java System Web Server 7 Technology Preview release has many new and cool features, one of which is its much improved command line administration support. Previous releases of the web server had very limited command line support for administration tasks. Web Server 7's primary command line administration tool is called wadm and it provides support for 280+ administration tasks!! I am very happy with the extensive command line support in the new release.

I started using wadm (wadm is located in the bin subdirectory of your web server installation) without knowing anything about its syntax.

% wadm
Usage: wadm [--user=admin-user] [--password-file=admin-pswd-file] [--host=admin-host] [--port=admin-port] [--no-ssl] [--rcfile=rcfile] [--no-prompt] [--help] [--commands-file=filename]
CLI014 user is a required option.


This didn't really tell me a lot, so I tried

% wadm -help
Usage: wadm [--user=admin-user] [--password-file=admin-pswd-file] [--host=admin-host] [--port=admin-port] [--no-ssl] [--rcfile=rcfile] [--no-prompt] [--help] [--commands-file=filename]
CLI011 Invalid option, e

Still no luck. I then noticed that -- was used to specify options and so I tried

% wadm --help

Voila! About 20 pages of help documentation scrolled past my eyes! I used a pager to read the help documentation.

% wadm --help | more

To get extended help on a specific command, all I had to do was to specify the command and the --help option

% wadm list-webapps --help | more

Quite intuitive and easy.

I discovered that wadm required that the administration server be running, so I started the administration server.

I found that wadm's command lines were quite long because of the various parameters that had to be specified for each command. Even using the abbreviated command line options (e.g. -u instead of --user, -h instead of --host etc.) I still felt that the amount of text that I had to type repeatedly was too much! For example, this is the command I had to type in order to list the Java web applications that were deployed on my server.


% wadm list-webapps --vs test --config test --user admin --host foobar --port 8989 --passwordfile /home/foobar/admin.passwd

And this is the command to add a Java web application archive to my server configuration

% wadm add-webapp --vs test --config test --user admin --host foobar --port 8989 --password-file /home/foobar/admin.passwd --uri /foo foo.war

Instead of the above, wouldn't it be cool if I could just type

% wadm add-webapp --uri /foo foo.war

to add a Java web application, or type

% wadm list-webapps

to list the Java web applications deployed on my server? I don't want to repeatedly type the parameter values that I know will never change and are common to most commands.

It turns out that wadm provides some nifty ways to facilitate this. This is what I found from reading wadm's help documentation.

Any option can be supplied to wadm using shell variables. The variable name equivalent for an option is derived by prefixing wadm_ to the option name and replacing all hyphens(-) in the option name with underscores(_). For example

Command Line Option Name Shell Variable Name
 user  wadm_user
 password-file  wadm_password_file
 receive-buffer-size  wadm_receive_buffer_size

Shell variables can be set in the following ways in their increasing order of precedence:

  1. Using environment variables in the shell from which wadm is invoked
  2. From within a .wadmrc file residing in the user's home directory
  3. Using set/unset commands within the wadm shell

I prefer not to use environment variables and so did not consider option #1 above. Instead, I tried #2 and #3.

Specifying command line option values in .wadmrc (option #2)

I created a file called .wadmrc in my home directory with my favourite editor and added the following to it:

set wadm_user admin
set wadm_password_file /home/foobar/admin.passwd
set wadm_port 8989
set wadm_vs test
set wadm_config test
set wadm_host foobar

Now when I use wadm, I never have to specify --user or --password-file or --port or --vs or --config or --host to any of my wadm commands! wadm automatically picks up these values from my .wadmrc file. (If you call the .wadmrc file by some other name or put it somewhere other than in your home directory, you must use the --rcfile option of wadm to identify your .wadmrc file.)

Specifying command line option values in the wadm shell (option #3)

I found that if I used the wadm shell then I needn't even type wadm! To invoke the wadm shell, I simply type wadm at the command line and this enters the wadm shell. You can tell its the wadm shell because the prompt changes from % to 'wadm> ' At the wadm> prompt, I simply type wadm commands. The shell allows me to override values specified in my .wadmrc file.


% wadm
Sun Java System Web Server 7.0 B05/09/2006 18:10
wadm>
wadm> help
wadm> list-virtual-servers
test
wadm> list-webapps
/foo
/bar
wadm> set wadm_vs foo
wadm> list-webapps
ADMIN3961: Specified virtual-server not found: foo
wadm> add-<TAB>

add-search-docs   add-webapp
wadm> set wadm_uri /test
/test
wadm> add-webapp foo.war
CLI201 Command 'add-webapp' ran successfully
wadm> list-webapps
/foo
/bar
/test
wadm> quit
%

As you can see from the sample session above, the wadm shell is an interactive shell that is very easy to use. It also has quite a powerful command line editor. For example you can use the arrow keys to  go up and down your command history or you can use the TAB key to complete commands or see the available options (see the add-<TAB> example above).

You can also do some pretty advanced Tcl scripting using wadm's --command-file option. I hope  to write about this in a separate blog in the near future.

Overall, I had a  pretty good experience using Web Server 7's wadm tool and I hope that you too will find it equally useful. I hope you will take Web Server 7 out for a test drive and send me feedback about it.

About

arvindsrinivasan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today