IBM WebSphere Application Server Community Edition (hereafter called Community Edition) is an open source Java™ Platform, Enterprise Edition (Java EE) application server, based on Apache Geronimo. Community Edition has a very small footprint and is available free of charge.
Community Edition's JSR-168-based administrative console is essentially a Web application, deployed in Community Edition, that provides a user friendly Web-based interface for administering many aspects of the local or remote server. If you are new to Community Edition and the administrative console, the article Using the Web console in WebSphere Application Server Community Edition will give you a good head start with many of the common administrative tasks that can be performed with the console. With that basic foundation, this two-part article will help you use the Community Edition console to perform advanced administrative tasks:
Part 1 discussed how to:
- Work with an IBM DB2® Express-C database.
- Create a DB2 Express-C database pool.
- Specify the database pool in the deployment descriptors.
- Create security realms.
- Create key stores.
This article looks at:
- Thread pools statistics.
- Redeploying an application from the console.
- Apache mod_jk configuration.
- Creating and installing Geronimo plug-ins.
Thread pool statistics
Performance tuning is always a priority task for administrators. The processing capacity of a server is based on the size of the thread pool, and so by looking at the thread pool status you can fine tune the server’s performance. This perspective is represented in the Thread Pools portlet, a new feature in the Community Edition V1.1.x administrative console.
You can launch the Thread Pools portlet from the Console Navigation pane by selecting the Thread Pools link under the Server category. The portlet displays the thread pools available on the server and the size of each pool (Figure 1).
Figure 1. Thread pool statistics
To monitor the statistics for a particular thread pool, click the monitor link corresponding to that pool. The size of the pool, lowest recorded, highest recorded, and the number of threads that are in use will display:
- Pool Max: The maximum number of threads that can be instantaited in a thread pool. If set to too low, this field reduces the throughput by throttling the CPU usage, in turn affecting performance (that is, increasing wait time of an application's request to be served). If set too high, CPU cycles are wasted on context switching among the threads.
- Lowest Recorded: The lowest number of threads used in the pool up to now.
- Highest Recorded: The highest number of threads used in the pool up to now.
- Threads in Use: The number of threads currently in use.
These fields provide a big picture for monitoring production load and analyzing pool usage so you can define the optimum value for your maximum pool size. With this information, you can can increase the processing capacity of the server by adjusting the maxThreads, minThreads, and acceptQueueSize parameters values in the config.xml file (located in the >i><wasce_home>/var/config directory). After making modifications, you must restart the server for any updated values to go into effect.
Redeploy an application from the console
At some point, you might encounter a situation where you need to make changes in your application code after the application has already been deployed in Community Edition. To put your changes into effect on the server, you must redeploy the updated application code. The new redeployment option on the admin console enables an easy, streamlined redeployment process, compared with the multiple steps required in previous versions of Community Edition.
To redeploy any application:
Uninstall and then re-install the application.
From the Console Navigation pane, select Deploy New under the Applications category to launch the Install New Applications portlet (Figure 2) on the console.
Provide values for the following fields:
- Archive: Browse to the application archive file that needs to be deployed.
- Plan: Browse to the Geronimo deployment plan file for the application (only if the plan is not packaged within the application archive file).
- Start app after install: Check box to start the application immediately after deployment.
- Redeploy application: Check box to redeploy an application that is already deployed on the server.
Click the Install button.
Figure 2. Redeploy an application
After successful redeployment, access the application URL to confirm the changes made to the application code are reflected on the server.
Clustering with Apache mod_jk
As your site traffic increases, you might reach a point when one application server running your application won't be enough to serve all the requests -- regardless of whether you built your application to support scalability or high-availabilty (fault tolerance). Should this occur, you will need to add additional servers to run your application -- however, this entire set of application servers running the identical application must still behave as a single entity. The mechanism that enables you to achieve this is known as clustering.
There are two general types of clustering:
- Vertical clustering: Running multiple nodes or instances of an application server on the same host.
- Horizontal clustering: Running multiple nodes or instances of an application server on different hosts.
Consider a cluster configuration when you want to improve the scalability and availability of your Web application. Community Edition provides Web tier clustering by implementing the clustering feature of Apache Tomcat. This clustering configuration enables cluster members to replicate httpsession data through memory-to-memory multicast communication. In addition:
Clustering improves availability by automatically synchronizing state data among all the nodes in a cluster. If any node in the cluster fails, subsequent requests can be processed by any other node in the cluster. This process is commonly referred to as failover and occurs on subsequent requests.
Clustering improves scalability by enabling you to increase system capacity by adding extra servers.
In Community Edition, you can configure both vertical clustering and horizontal clustering.
JK is a component used for communication between Web servers and Apache Tomcat connectors. More specifically, JK is the Tomcat/Apache plug-in that handles the communication between a Tomcat servlet container and an Apache HTTP Server, and comes as an Apache HTTP Server module (see Resources). The latest implementation of JK is known as mod_jk, which uses AJP protocol to facilitate the communication between the container and the server. Community Edition uses Tomcat as its Web container, and so also uses mod_jk for accessing Apache HTTP Server. You can also set up a load balancer between Community Edition and Apache HTTP Server using the mod_jk module, which would spray the incoming requests to each available members in the cluster.
To configure mod_jk, these steps must occur:
Configure the Community Edition Web container to support the AJP protocol
The Apache AJP protocol is packet-oriented and enables the Web server to communicate with the JSP/servlet container over TCP connections. Again, AJP is used here by Apache HTTP Server to communicate with Tomcat embedded in Community Edition.
To cut down on the expensive process of socket creation, the Web server attempts to maintain persistent TCP connections to the servlet container, and attempts to reuse a connection for multiple request/response cycles. Once the Web server has opened a connection to the servlet container and assigned a connection to a particular request, it will not be used for any other requests until the request handling cycle has terminated. This makes the code at either end of the connection simpler -- although it does cause more connections to be open at once.
Once a connection is assigned to handle a particular request, the basic request information (HTTP headers, and so on) is sent over the TCP connection as a packet. At this point, the servlet container is presumably ready to start processing the request and sends the formatted packet of reply messages back to the Web server.
Install the mod_jk.so Apache module
You should install mod_jk in the modules directory of your Apache Web server (for example, in
/usr/lib/apache) and then update your httpd.conf to point to mod_jk.so by adding this line:
LoadModule jk_module modules/mod_jk.so
Create a workers.properties file
A worker is basically a Tomcat listener. It waits for information from Apache and gives it to Tomcat to execute. For example, a Web server can forward requests to a Tomcat process (the worker) running behind it. Tomcat workers are defined in a workers.properties file. HTTPd makes use of this file to find out where the Community Edition server is running, what version of AJP should be used, and to which port the Community Edition server is listening.
Create a workers.properties configuration file to point Apache HTTP Server to the Community Edition's AJP Connector. (A sample workers.properties can be found under the
confdirectory of your Apache installation.) Add the line below to the httpd.conf file to point to this new file:
Add Apache configuration information
With a Tomcat worker defined, you now need to tell Apache to talk to that worker. You must also indicate which URLs should be sent to Community Edition, and whether Apache should serve static content (leaving the dynamic content within the Web application to be served by Community Edition). You do this by updating the corresponding values in Apache's <apache_home>/conf/httpd.conf file.
As an alternative to performing the above four steps manually, you can easily configure the mod_jk module using the Apache HTTP portlet from the console:
Launch the Apache HTTP portlet from the Console Navigation pane by selecting the Apache HTTP link under the Server category. Figure 3 shows the Apache mod_jk - Basic configuration portlet. (For this feature, Community Edition does not maintain a history of settings generated using the console, and therefore you will need to re-enter data each time.)
Figure 3. Apache Mod_jk -- Basic configuration
The mod_jk installation process depends on the operating system, so select your operating system from the list. If your operating system is not listed, you need to install mod_jk yourself:
- Download the mod_jk binary for your operating system from the Apache Jakarta Tomcat Connector libraries site. (If binaries are not available for your operating system, then you need to build mod_jk from the source. See Obtaining mod_jk for information on building mod_jk in Apache.)
- To enable mod_jk in Apache, install the mod_jk.so
(Linux/UNIX/Mac OS X) or mod_jk.dll (Windows) file on the
modules directory of your Apache Web server, and then add the
line below to the httpd.conf file:
LoadModule jk_module modules/mod_jk.so
- Start (or restart) Apache HTTP Server.
Enter values for the following fields:
- Path to workers.properties: Specify where you want to save the workers.properties file.
- mod_jk log file location: Specify where you want to keep the log files.
All the Web applications that are currently running in Community Edition are listed in the Apache mod_jk - Web App Selection portlet (Figure 4). For each application listed:
- Select Through Apache if the Web application should be exposed through Apache.
- Select Static Content if you want Apache to serve the static content for the application.
- Specify the URL in the Dynamic Paths field if Apache is serving static content for the application.
Figure 4. Apache Mod_jk - Web App Selection
Click Finish to complete the Apache mod_jk configuration. The Configuration Results portlet (Figure 5) will display. Any Web applications to be exposed via Apache must be running and accessible from Apache when you run the mod_jk configuration portlet.
Figure 5. Apache Mod_jk -- Configuration Results
Figure 5 shows the steps necessary to enable mod_jk in Apache and configure it to talk to Community Edition. Complete these instructions and click Done.
Start Community Edition Server and restart Apache. Try accessing a Web application through Apache (that is, provide the Apache URL). You should see the corresponding log messages from the Apache error log and the mod_jk error log.
A sample application for Community Edition's clustering feature is available for download from the Community Edition download page. (Select your operating system in the Download section. On the next page, select Sample J2EE applications in the Add-ons section, then Download now.) You can deploy this application on Community Edition and access it through Apache.
Create and install Geronimo plug-ins
A Geronimo plug-in is basically a complete configuration of an application or service that runs in Apache Geronimo, packaged in a .zip file format. Using the Geronimo plug-ins feature, you can export any configuration from one Geronimo server to a remote repository as a plug-in and then import it to any other Geronimo server. These plug-ins can be installed at run time; Geronimo automatically downloads and installs all the plug-in's dependencies (JARs or other plug-ins) at the time the plug-in is installed. This feature is very useful for distributed environment scenarios, in which you can install the same configuration on several servers without repeating manual configuration steps on each server.
To create and install Geronimo plug-ins from the console, go to the Console Navigation pane, select the Create/Install link under the Plugins category, and then follow the instructions below:
Create Geronimo plug-in
On the Create and Install Plugins portlet (Figure 6), select the configuration you want to export from the drop-down box under Create Geronimo Plugin. Click the Export Plugin button.
Figure 6. Create and Install Plugins
In the Configure Plugin data portlet (Figure 7), enter or select values for these fields:
- Human Readable Name: Any descriptive name for the plug-in.
- Unique ID: Globally unique ID that defines the version number for the plug-in.
- Download Repositories: List the repository
URLs for Geronimo to check for any dependencies that need to
be downloaded (done automatically at plug-in install time).
- Category: Assign a category to the plug-in to document its purpose; for example: Security, Scheduling, Portal, Monitoring, and so on. (See Geronimo Plugins for more information.)
- Description: Any descriptive text to describe the plug-in.
- Plugin URL: Specify a URL to get more
information about the plug-in; for example, the plug-in home
- Author: (optional) Can be an individual, company name, open source project, or any applicable value.
- License: (optional) Important when sharing software or a configuration. (See Open Source License Index.)
- Open Source: Select this box if the license is an OSI-approved open source license. (See Open Source License Index.)
- Geronimo Versions: Indicate the Geronimo
versions supported by this plug-in, in the format:
1.1 /n 1.1.1 /n 1.1.2 /n ...and so on. (Listing no values indicates that the plug-in can be installed in any version of Geronimo.) This implies you have actually tested the plug-in with whatever Geronimo versions you have listed here.
- JVM Versions: Specify the JVM version
prefixes supported by this plug-in, in the format:
1.4.2 /n 1.5 /n ...and so on. (Listing no values indicates that the plug-in can be installed in Geronimo running in any version of the JVM.) This implies you have actually tested the plug-in with Geronimo on each JVM version you have listed here.
- Obsoletes: Enter the list of module IDs that the plug-in replaces. Those plug-ins or modules will be removed when this one is installed. This can include previous versions of this plug-in if you want the installation of the new one to "upgrade" what exists, rather than just offer another alternative.
- Prerequisite: Enter details of any
prerequisite, if any exist. A prerequisite is a module that
must be present in the server before the plug-in can be
installed, and could be something like a specific Web
container for an application (such as:
geronimo/jetty/*/car) or a database pool or security realm that the user must install (because the plug-in author can't create a value that will be valid in the destination server).
Figure 7. Export Plugin - Configure Plugin Data (partial view)
Click Save Plugin Data to save the plug-in configuration.
Click Export Plugin to save the plug-in to your local file system as a CAR (Configuration Archive) file.
Currently, to be a valid plug-in, you must add a META-INF/geronimo-plugin.xml file to the CAR manually after exporting it. Create the geronimo-plugin.xml code as specified in Listing 1, substituting applicable values. This sample code shows the name of the plug-in, module-id, category, plug-in URL, author, and the license information of the plug-in. See Geronimo Plugins for sample plug-ins available for each category and more information about them all.
Listing 1. geronimo-plugin.xml
<?xml version="1.0" encoding="UTF-8"?> <geronimo-plugin xmlns="http://geronimo.apache.org/xml/ns/plugins-1.1"> <name>Jakarta JSP Examples (Tomcat)</name> <module-id>geronimo/jsp-examples-tomcat/1.1.1/car</module-id> <category>Examples</category> <description>The JSP examples originally developed for Tomcat.</description> <url>http://geronimo.apache.org/</url> <author>The Apache Geronimo development community</author> <license osi-approved="true">BSD -- Apache Software License (ASL) 2.0</license> <geronimo-version>1.1.1</geronimo-version> <prerequisite> <id>geronimo/tomcat//car</id> <resource-type>Web Container</resource-type> <description> This version of the JSP Examples works with the Geronimo/Tomcat distribution. </description> </prerequisite> <dependency>geronimo/j2ee-server//car</dependency> <source-repository> http://www.geronimoplugins.com/repository/geronimo-1.1/ </source-repository> <source-repository>http://www.ibiblio.org/maven2/</source-repository> </geronimo-plugin>
Install Geronimo plug-in
In the Install Geronimo Plugin section (Figure 8) of the Create and Install Plugins portlet (Figure 6), provide values for the following fields:
- Repository: Select the URL of the remote
repository from where you want to import the plug-in. For
- User, Password: These values are optional.
Click Search for Plugins to list all the Geronimo plug-ins available in the selected repository.
Figure 8. Install Geronimo plugin section
- Repository: Select the URL of the remote repository from where you want to import the plug-in. For example:
Select the required plug-in, such as Jakarta JSP Examples (Tomcat).
Click Install Plugin (Figure 9). The plug-in is downloaded and installed automatically, along with all the required dependencies (JARs or other plug-ins) from the repository site (Figure 10).
Figure 9. Install Plugins
Figure 10. Download plug-in from remote repository
After successful installation, click the Start <plugin name> button (in this case, Start geronimo/jsp-examples-tomcat/1.1/car) to start the installed application or service as a plug-in (Figure 11).
Figure 11. Start the installed plug-in configuration
The successful installation of the plug-in will also be shown in the command window in which the Community Edition server is started (Figure 12).
Figure 12. Plug-in deployment success
In case the remote repository you are looking for is not listed in the Repository field, you can add the repository to the list that is displayed:
On the Create and Install Plugins portlet (Figure 6), click Add Repository in the Install the Geronimo plug-ins section. The Add Plugin Repository portlet displays, showing all the available plug-in repositories (Figure 13).
Figure 13. Add new plugin Repository
Enter the URL of the remote repository in the New Repository field. For example:
The repository should have a geronimo-plugins.xml file in the root directory that lists the available plug-ins in the repository.
You can also now download the running configurations from another Community Edition server by specifying the URL of the remote server in the New Repository field, such as:
Click the Add Repository button.
Now the plug-in repository you have specified is added into the repository list. This will become available in the Install Geronimo plugin section (Figure 6 and Figure 8).
Remove Geronimo plug-in
The Geronimo plug-in gives you the ability to install an application or service that runs in Geronimo, or a complete configuration. However, if you do not want any of the configurations that are installed by the Geronimo plug-in, you can simply uninstall those configurations by removing the corresponding plug-ins from the server. To remove a plug-in from the Console Navigation pane of the admin console, locate the plug-in module under the Applications section, and uninstall it.
Part 2 of this series on advanced system administration described new administrative console features available in WebSphere Application Server Community Edition V1.1, including::
- Setting up a load balancer between Community Edition and an Apache HTTP Server using the Apache mod_jk module, and enabling access to an application on Community Edition through Apache.
- Tuning server performance by reviewing thread pools statistics.
- Importing the configuration of an application or service from one server to another using the Geronimo plug-in feature.
Be sure to see Part 1, as well as the Resources provided below to learn more about new features in WebSphere Application Server Community Edition that make it better, easier, and more flexible than ever.
More in this series
- WebSphere Application Server Community Edition resources
- WebSphere Application Server Community Edition product documentation
- Using the Web console in WebSphere Application Server Community Edition
- Get started with WebSphere Application Server Community Edition
- Configuring Tomcat and Apache With JK 1.2
- Working with mod_jk
Get products and technologies
- Download WebSphere Application Server Community Edition V1.1
- Download Apache mod_jk
- Geronimo Plugins
- Download Apache HTTP Server
- IBM WebSphere Application Server Community Edition and Apache Geronimo forum
- Get involved in the developerWorks community