Services: DevOps Thought Leadership | JEE Consulting
Configuring Apache HTTP Server V2.2 - background
This topic describes how to change configuration settings for Apache HTTP Server Version 2.2.
Install Apache 2.2 and the latest version of the Web server plug-ins for WebSphere Application Server 7.0 using the UpdateInstaller.
Apache HTTP Server v2.2 is different from IBM HTTP Server (powered by Apache). When you install the Web server plug-ins for WebSphere Application Server on a non-iSeries system, the Plug-ins installation wizard configures the Web server.
This topic describes how to configure the Apache HTTP Server Version 2.2 Web server. Other procedures in Editing Web server configuration files describe configuring other supported Web servers.
If you are using an Apache HTTP Server that supports 64-bit addressing, you must use the 64-bit CD provided with the WebSphere Application Server product to install the Apache Web server plug-in binaries. If you use the 32-bit CD, you will receive an error message indicating that the plug-in binaries did not load.
If you are using an Apache HTTP Server that supports 32-bit addressing, you must use the 32-bit CD provided with the WebSphere Application Server product to install the Apache Web server plug-in binaries. If you use the 64-bit CD, you will receive an error message indicating that the plug-in binaries did not load.
A sample error message follows:
httpd: Syntax error on line XXX of /home/apache/conf/httpd.conf: Cannot load /home/apache/Plugins/mod_was_ap22_http.sl into server: Invalid argument
The plug-in was tested with the threaded worker multi-processing module (MPM) on all platforms except Windows. The plug-in was tested with the default threaded MPM on Windows.
The plug-in works with the Apache 2.2 prefork MPM but works best with the worker MPM. The plug-in maintains connection pools to backend WebSphere Application Servers and uses in-memory caching. These plug-in functions perform most efficiently when Apache is configured to use a single child process with the ThreadsPerChild value equal to the MaxClients value. The plug-in can be used with the prefork MPM or the worker MPM that is configured with multiple child processes, but at reduced efficiency.
Compatibility Statement The plug-in works with versions of the Apache HTTP Server that claim full binary compatibility with Apache 2.0.47 and later, which are built with compilers and compiler options that are compatible with those used to build the plug-in.
Perform the step that configures Apache 2.2 for your operating system.
Examples and messages are shown on more than one line for clarity. Place each directive in a Web server configuration file on one line.
Local file path means a file path to the plugin-cfg.xml file on an Application Server that is on the same machine as the Web server. Remote file path means the file path to the plugin-cfg.xml file when the Application Server is on a remote machine. The Plug-ins installation wizard installs a dummy plugin-cfg.xml file during installation, but this file requires periodic propagation from the real file on the Application Server machine.
The node_name in the following Application Server local file paths is web_server_name_node for a stand-alone Application Server or managed_node_name for a managed node.
The name of the Web server definition in the following steps is webserver1.
[AIX] Configure entries in the httpd.conf file.
Use the following examples of the LoadModule and the WebSpherePluginConfig directives as models for configuring your file:
Local distributed example:
[Linux] [Solaris] Configure entries in the httpd.conf file.
[Solaris] On the Solaris SPARC 64-bit platform, the Plug-ins installation wizard installs both 32-bit and 64-bit versions of the plug-in for Apache 2.2, however it configures the Web server to use the 32-bit plug-in only. If the Web server is 64-bit, you need to configure the LoadModule directive in the httpd.conf file to use the 64-bit plug-in as follows:
[HP-UX] Configure entries in the httpd.conf file.
[Windows] Configure entries in the httpd.conf file.
The Apache 2.2 Web server is reconfigured.
The Plug-ins installation wizard installs the GSKIT SSL encryption library at the required level if it is not installed. If you manually copy the plug-in to a new machine, you might not have the required GSKIT libraries for encrypting back-end connections.
After configuring a Web server, you can install applications on it. See the Applications section of the information center for more information.
1. cd lin_x64_suppl/plugin
3. Skip docs step, Accept License, click Next
4. Select Apache Web Server V2.2, then click Next
5. If Apache and Was plug are installed on the same machine as the DM, and cluster nodes then choose local. For multiple Apache instances ie ot be used with a lod balancer then you would do this for [n] Apache nodes.
Select node01 profile.
Note: On a vertical cluster ie all nodes are on same physical machine and we have only one apache server on same machine then we only need actual set of plug-in binaries for apache. If Apache is on 2 machines then we install it twice. We also need to manually create web server definitions for all nodes in the cluster.
Restart the deployment manager as the wizard has created a web server definition (web server01) and needs to be picked up. Note: we could have done this web server definition manually in WAS admin console..
Best to restart Apache to check it is ok.
LoadModule was_ap22_module /var/apps/was7nd_apache/plugins/bin/64bits/mod_was_ap22_http.so
Are added to http.conf. You can see that the actual plugin binaries are located /var/apps/was7nd_apache/plugins… and could be anywhere, maybe even located near apache install if you want.
Let’s log into the admin console to see the webserver01 definition.
Save, before we create another one , lets test it.
Wizard breaks, need to update httpd.conf to correct location for mod_was_ap22_http.so
#LoadModule was_ap22_module /var/apps/was7nd_apache/plugins/bin/64bits/mod_was_ap22_http.so
LoadModule was_ap22_module /var/apps/was7nd_apache/bin/64bits/mod_was_ap22_http.so
To find where apche is installed
You can use WAS variables like $(APCHE_INSTALL_ROOT}/bin/apachectl, but I am using full path as admins might not want to add WAS variables.
Start command arguments
Save changes and you should see that Apache process can be seen by web server definition. You cannot stop and start due to bugs in WAS.
Enable automated Web server configuration processing
The service automatically generates the plug-in configuration file whenever the Web server environment changes, with a few exceptions. For example, the plug-in configuration file is regenerated whenever one of the following activities occurs:
· A new application is deployed on an associated application server
· The Web server definition is saved
· An application is removed from an associated application server
· A new virtual host is defined
In WebSphere Application Server, Network Deployment configurations, the plug-in configuration file does not regenerate when:
· A cluster member is added to a cluster.
· TCP channel settings are updated for an application server.
By default, this option is selected. Clear the field to disable automated Web server configuration processing.
You can change the timing, but best to leave as default.. When scripting we can call commands to do this.
Install default application to get snoop servlet
Next past application setting screen and map modules to servers. The provides details for the plugi-cfg.xl file which us used to tell Apache of the clusters and server etc.
Make sure all web modules are bound to both the cluster and the web server.
Save installation. Note: ,you can also go back in to application settings and re-map modules to servers.
Ensure that the cluster is started.
Result, the plugin-cfg.xml is updated with the URL paths for mapped applications and contain cluster state.
Then click Propagate
Result, the plugin-cfg.xml is copied to the location that apache is looking for this file as specified in httpd.conf
Restart Apache every time the Plugin is propagated
cd /var/apps/was7nd_apache/plugins/webserver01 to see the plugin-cfg.xml has been updated
<Config ASDisableNagle="false" AcceptAllContent="false" AppServerPortPreference="HostHeader" ChunkedResponse="false" FIPSEnable="false" FailoverToNext="false" HTTPMaxHeaders="300" IISDisableNagle="false" IISPluginPriority="High" IgnoreDNSFailures="false" RefreshInterval="60" ResponseChunkSize="64" SSLConsolidate="false" TrustedProxyEnable="false" VHostMatchingCompat="false">
<Log LogLevel="Error" Name="/var/apps/was7nd_apache/plugins/logs/webserver01/http_plugin.log"/>
<Property Name="ESIEnable" Value="true"/>
<Property Name="ESIMaxCacheSize" Value="1024"/>
<Property Name="ESIInvalidationMonitor" Value="false"/>
<Property Name="ESIEnableToPassCookies" Value="false"/>
<Property Name="PluginInstallRoot" Value="/var/apps/was7nd_apache/plugins/"/>
<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="Cluster01" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
<Server CloneID="1631jggec" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="node01_server02_clone1" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9082" Protocol="http"/>
<Transport Hostname="localhost" Port="9445" Protocol="https">
<Property Name="keyring" Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.kdb"/>
<Property Name="stashfile" Value="/var/apps/was7nd_apache/plugins/config/webserver01/plugin-key.sth"/>
<Server CloneID="1631jgho8" ConnectTimeout="5" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="node02_server02_clone2" ServerIOTimeout="60" WaitForContinue="false">
<Transport Hostname="localhost" Port="9083" Protocol="http"/>
<Transport Hostname="localhost" Port="9446" Protocol="https">
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/snoop/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hello"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/hitcount"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/j_security_check"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/ibm_security_logout"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/servlet/*"/>
<Route ServerCluster="Cluster01" UriGroup="default_host_Cluster01_URIs" VirtualHostGroup="default_host"/>
<RequestMetrics armEnabled="false" loggingEnabled="false" rmEnabled="false" traceLevel="HOPS">
<filters enable="false" type="URI">
<filterValues enable="false" value="/snoop"/>
<filterValues enable="false" value="/hitcount"/>
<filters enable="false" type="SOURCE_IP">
<filterValues enable="false" value="255.255.255.255"/>
<filterValues enable="false" value="254.254.254.254"/>
<filters enable="false" type="JMS">
<filterValues enable="false" value="destination=aaa"/>
<filters enable="false" type="WEB_SERVICES">
<filterValues enable="false" value="wsdlPort=aaa:op=bbb:nameSpace=ccc"/>
http://192.168.0.71:9082/snoop -> node01
http://192.168.0.71:9083/snoop - >node01
First refesh for node see port below is 9082 which is node 01 cluster clone 01 (server 01)
Second refresh on Apache produces port 9083 which is Node 02, cluster clone 02 (server 02)
Session Affinity (Sicky sessions)
Specifies whether the plug-in ignores the number of affinity requests made to a server when selecting servers based on the Round Robin algorithm. Specify zero or one attribute for each ServerCluster. The value is true or false. If the value is set to false, the number of affinity requests made is also taken into account in the server selection process.
The default value is true, which means the number of affinity requests made are not used in the Round Robin algorithm.
By default, when using Apache and Plugin, the JSESSIONID that you get remains for that session until application clears that session cookie ie logout or the browser gets closed or the server fails over, however The plugin by default has IgnoreAffinityRequests="true" and we need to make this false.
After adding properties for the plug-in, Re-generate the plug-in-cfg.xml and propagate to Apache.
Some basic background on how WAS deals with “sticky sessions”.
The WebSphere Plugin for Apache can detect fail over
• Detects failure in the WAS web container, then marks the web container as unavailable ie the URI set is changed.
• The request is then routed to the next available web container Of a clone in a cluster. Thus all of this requires WAS ND and clusters. As new cluster members (Clones) are added to the cluster, the plugin-cfg.xml files needs to be re-generated and propagated to Apache. These step are outlines above.
• In-flight sessions can be persisted to a data base and can be replicated to other cloves via memory-to-memory replication.
• You set up persistence to save sessions in case of failure during access and replication ensures that once a session is failed over the sessions are available from the next clone’s web container
High Availability of Sessions
Session objects are volatile, and so are lost if the server fails or is restarted.
There are two methods to provide session high availability i.e. persisted in the event of server failure.
• Session are stored in a session database
• Uses JDBC
• Greater overheard, but guaranteed.
• Session are replicated to each server via the internal messaging provider
• Less overhead, not guaranteed
Setting up session persistence
Must be applied to each server/clone. So they participate in session replication
Creating a DB for session persistence
How create a DB for session persistence and setup a JDBC data source as required.
Create a Schema / Creating a table for session persistence
To be verified…
You can use a database table to collect and store session data. If you are using a database table for session persistence, you must create and define a database table that is associated with the application server.
Whenever the session manager is set for database persistence, the session manager creates a table for its use. If you want to expand the column size limits to make it more appropriate for your Web site, you can create the table externally. If the external table is specified as the target table in the session manager database persistence configuration, then during the session manager start up, the external table is used. In most cases it is better to let the session manager create the table during startup.
To create a table for collecting session data, do the following:
CREATE TABLE <SchemaName>.sessions (
ID VARCHAR(128) NOT NULL ,
PROPID VARCHAR(128) NOT NULL ,
APPNAME VARCHAR(128) NOT NULL,
LISTENERCNT SMALLINT ,
MAXINACTIVETIME INTEGER ,
USERNAME VARCHAR(256) ,
SMALL VARCHAR(3122) FOR BIT DATA ,
MEDIUM LONG VARCHAR FOR BIT DATA ,
CREATE TABLE SESSIONS (
MEDIUM LONG RAW ,
If the Web container custom property UseOracleBLOB is set to true then:
At run time, the session manager accesses the target table using the identity of the J2EE server in which the owning Web application is deployed. Any Web container that is configured to use persistent sessions must have both read and update access to the subject database table.
HTTP session processing uses the index defined using the CREATE INDEX statement to avoid database deadlocks. In some situations, such as when a relatively small table size is defined for the database, DB2 may decide not to use this index. When the index is not used, database deadlocks can occur. If database deadlocks occur, see the DB2 Administration Guide for the version of DB2 you are using for recommendations on how to calculate the space required for an index and adjust the size of the tables that you are using accordingly.
It might be necessary to tune DB2 to make efficient use of the sessions database table and to avoid deadlocks when accessing it. Your DB2 administrator should refer to the DB2 Administration Guide for specific information about tuning the version of DB2 that you are using.
[Updated in February 2011] During run time, the session manager may create an entry in the database for each web module of the application. This row of data is used internally for session management purposes, such as in session invalidation. Do not be concerned with this entry. It can be overlooked. [Updated in February 2011]
Create a Data source / J2C alias
Create the appropriate setting in the server’s environment settings
Configuring a table for session persistence
To configure a table for collecting session data, you must add the name of the table to the Web container configuration properties.
If you are using database for session persistence, you must create and define a database table to the application server to collect session data.
To configure a table for collecting session data, use the administrative console to add the name of this table to the Web container's configuration properties:
1. Open the administrative console.
2. Click Servers > Server Types > WebSphere application servers.
3. Select a server from the list of application servers.
4. Under Additional Properties, click Web Container.
5. Under Additional Properties, click Custom properties.
6. Click SessionTableName to configure the DB2® table, or click New to create a new property.
7. Specify 'SessionTableName' in the Name field if you are creating a new property. In the Value field, enter the name of the session table. The value must have the form, schema_name.table_name. For example, if the schema name is DB2ADMIN and the table name is SESSIONS, enter DB2ADMIN.SESSIONS for Value. Optionally, you can update the description of this table in the Description field. For example, you might enter "Table name for HTTP session data."
8. Click Apply > Save.
9. When the product is restarted, the session management facility creates the new SESSIONS table in the specified tablespace.
….to be verified …
How to configure session replication
You can create a replication domain for memory only.
How to tune session replication
Tips and settings on how to tune Memory-to-Memory session replication.
· Single replica
o For every session there will be a copy stored on a different server/clone. This copy is then used to failover when a server become unavailable.
o Sessions are copied to every member in the replication domain and every member has to store all the copies from all other members, so performance can be an issue
o As the setting says, you can specify the number of replicas to use in the cluster. Replicas , this way you can tune how may replicas of the session information exist.
Plug-in Administration Service
Plug-in Administration Services is set by default, but good to check.
Steve Robinson has been working in IT for over 20 years and has provided solutions for many leading brands around the world. Steve specialises in JEE, DevOps and Thought Leadership.
In January 2013, I was awarded the prestigous 'IBM Champion' accolade.
IBM WebSphere Application Server 8.0 Administration Guide
WebSphere Application Server 7.0 Administration Guide
Contact | Articles | Shell Scripts | Java Code | JACL | Jython | WebSphere MQ | WebSphere Message Broker | WebSphere Blog | © Copyright 2006-2013 Robinson (UK) Limited