Web Server Plug-in Coexistence for V3.5 and V4.0 or V5.0
 Technote (troubleshooting)
 
This document applies only to the following language version(s):
US English
 
Problem(Abstract)
You can configure your web server to route requests to both WebSphere® Application Server V3.5 and V4.0 or V5.0. By loading the plug-in for both versions, a single web server can handle requests for both application servers. This document outlines the considerations and limitations for a plug-in coexistence configuration.
 
Cause
You want to configure a single web server to route requests to both a V3.5 application server and a V4.0 or V5.0 application server.
 
Resolving the problem
Statement of Support
IBM supports WebSphere Application Server V3.5.4-3.5.7 and V4.0.2-4.0.7 or V3.5.4-3.5.7 and V5.0-5.0.2 plug-in coexistence configuration when WebSphere Cumulative Plugin fix PQ76785 (or any of its future replacements) and WebSphere 4.0 Cumulative plug-in fix dated Oct 1,2003 or later are installed.

IBM supports V3.5.4-3.5.7 and V5.0-5.0.2 plug-in coexistence configuration when WebSphere Cumulative Plugin fix PQ76785 (or any of its future replacements) and V5.0 Cumulative plug-in fix dated Sep 3, 2003 or later are installed.

Minimum recommended web server versions for V3.5 and V4.0 plug-in coexistence:
  • IHS 1.3.19.5
  • IHS 1.3.26.2
  • iPlanet 4.1 SP7
  • iPlanet 6.0 SP1
  • Domino 5.0.9a
  • IIS 4 on Windows NT
  • IIS 5 on Windows 2000

Minimum recommended web server versions for V3.5 and V5.0 plug-in coexistence:
  • IHS 1.3.26.2
  • iPlanet 6.0.4
  • Domino 5.0.9a
  • Domino 6.0.2
  • IIS 4 on Windows NT
  • IIS 5 on Windows 2000
  • Apache 1.3.26

For more information on prerequisites, review this Web site:

http://www-3.ibm.com/software/webservers/appserv/doc/latest/prereq.html

Features that are present in V3.5.6 and PQ76785 plug-in that must be considered:

In the V3.5.4 and 3.5.5 plug-in, the VirtualHost matching is done against the port number of the web server that the request was received on. In the V3.5.6 and later plug-in, the VirtualHost matching is done against the port number that is parsed from the host header. This behavior fully complies with HTTP 1.1 spec and there is not any available parameter in the plug-in that can set the old behavior. PQ76785 is built on top of WebSphere 3.5.7 code. It means, that after you install the Cumulative Plug-in fix PQ76785, the algorithm of how the plugin matches the port number of the incoming http request, is changed. This is important to remember, that the plug-in matching algorithm has changed, after you install PQ76785 to V3.5.4 or 3.5.5 configurations (PQ76785 is not available for V3.5.3 and below). IBM strongly recommends that you test this fix on your test system before you apply it to your production system, so that you can learn what other additional changes in VirtualHost mappings are needed.

Features of the V4.0 plug-in that may need to be considered:

VHostMatchingCompat flag - this parameter sets how the VirtualHost matching algorithm in the plug-in works. In V4.0 the VirtualHost matching can be done against the port number that the request was received on, or against the port number that is parsed from the host header. In V5.0 plug-in the VirtualHost matching is done only against the port number that is parsed from the host header. This behavior complies with HTTP 1.1 spec. This flag is supported only in V4.0 and currently not applicable in V5.0. There is a plan to support this flag in a future V5.0 Cumulative plug-in fix.

AppServerPortPreference flag - this option allows you to choose the behavior of what port number the Application server uses in building URI's for a sendRedirect. In V4.0 it can be the port number from the host header of the http request coming in, or the port number that the web server received the request on. In the V5.0 plug-in, it is only the port number from the host header of the http request coming in, which fully complies with HTTP 1.1 spec. This flag is supported only in V4.0 and currently not applicable in V5.0. There is a plan to support this flag in a future V5.0 Cumulative plug-in fix.

Decide whether you will use the same domain name or separate domain names for the V3.5 instance and the V4.0 or V5.0 instance

This is probably the most important step before you configure the V3.5 and V4.0 or V5.0 plug-in for coexistence. It is not required, but IBM recommends that you configure a separate domain name in the web server for each instance of WebSphere Application Server. If this is not possible, or if it does not fit your business need, both instances of WebSphere can be configured with the same domain name to access V3.5 and V4.0 or V5.0 applications, but some additional configuration steps may be needed.

Example assumptions:

All of the plug-in examples provided in this document assume the use of IBM HTTP Server 1.3 (such as IHS 1.3.19.x or IHS 1.3.26.x) web server. This approach should be applicable to any web server that is supported for V3.5 and V4.0 or V3.5 and V5.0 plug-in coexistence.

For the sake of simplicity, the examples below will use myApp35 which is a WebModule (Web Application) deployed in V3.5 with a ContextRoot (Web Application Path) myApp35. The myApp40 is WebModule of the Enterprise Application deployed in V40 with a ContextRoot myApp40. You can use a similar approach when you configure V5.0 for plug-in coexistence with V3.5.

Example #1: Each instance of WebSphere will be accessed thru its own domain name in the web server

Configure two IP Based VirtualHosts in IHS (httpd.conf), each with a unique IP address.

For Example:

Listen 80

<VirtualHost 10.10.10.1:80>
ServerName mysite35.com
DocumentRoot /www/docs/mysite35
ErrorLog logs/mysite35-error.log
CustomLog logs/mysite35-access.log common
</VirtualHost>

<VirtualHost 10.10.10.2:80>
ServerName mysite40.com
DocumentRoot /www/docs/mysite40
ErrorLog logs/mysite40-error.log
CustomLog logs/mysite40-access.log common
</VirtualHost>

or if you prefer NameBased VirtualHosting (there are some restrictions for SSL VirtualHosts in IBM HTTP Server):

Listen 80
NameVirtualHost 10.10.10.1

<VirtualHost 10.10.10.1:80>
ServerName mysite35.com
DocumentRoot /www/docs/mysite35
ErrorLog logs/mysite35-error.log
CustomLog logs/mysite35-access.log common
</VirtualHost>

<VirtualHost 10.10.10.1:80>
ServerName mysite40.com
DocumentRoot /www/docs/mysite40
ErrorLog logs/mysite40-error.log
CustomLog logs/mysite40-access.log common
</VirtualHost>

Configure VirtualHost in V3.5 and VirtualHostsGroup in V4.0 with corresponding aliases.

For Example:

a) In V3.5 configure VirtualHost_myApp35 VirtualHost
www.mysite35.com:80
10.10.10.1:80

b) In V4.0 configure VirtualHost_myApp40 VirtualHostGroup
www.mysite40.com:80
10.10.10.2:80

In the case of using NameBased VirtualHosts in IHS, do not add the IP address alias in any VirtualHostGroup. Unexpected results may occur since both VirtualHosts have the same IP address.

Example #2: Both instances of WebSphere have the same domain name in the web server

When serving a request, the plug-in searches to match both VirtualHost and URI (Servlet Web Path list) mappings. In this case the VirtualHost is common to both the V3.5 and V4.0 environments, so the URI mapping must be unique. Any overlap can cause unexpected results.

Configure IP Based VirtualHost in IHS.

For Example:

Listen 80

<VirtualHost 10.10.10.1:80>
ServerName mysite.com
DocumentRoot /www/docs/mysite
ErrorLog logs/mysite-error.log
CustomLog logs/mysite-access.log common
</VirtualHost>

Configure VirtualHostsGroup in V4.0 and V5.0 with corresponding aliases, such as:

a) In V3.5 configure VirtualHost_myApp35 VirtualHost
www.mysite.com:80
10.10.10.1:80

b) In V4.0 configure VirtualHost_myApp40 VirtualHostGroup
VirtualHost_myApp40 with only one alias:
www.mysite.com:80
10.10.10.1:80

Additional considerations

There are two plug-ins loaded (V3.5 and V4.0 or V3.5 and V5.0) when configuring plug-in coexistence.

The order in which the plug-in modules are loaded may be important for performance reasons. For example, if most of the http requests are directed to V4.0, then load the V4.0 plugin first. This orientation of plugin loads will minimize the V3.5 involvement in handling requests. This approach works in scenarios where most http requests (based on your historical access statistics) should be routed to V4.0 instead of V3.5.

When serving a request, the WebSphere plug-in searches for the all possible matches of VirtualHost and URI mappings. In V3.5 these mappings are defined in the queues, rules and vhost properties files and some important plug-in settings are also defined in the bootstrap property file. In V4.0 or V5.0, all VirtualHost and URI mappings and other needed definitions for the plug-in are set in the plugin-cfg.xml file, which is called WebSphere plug-in configuration file. In this case, where the web server is common for both V3.5 and V4.0 or V5.0 plug-ins, the combination of VirtualHost and URI mappings must be unique across all V3.5 and V4.0 or V5.0 plug-in configuration files. If not, you may get unexpected results, such as the request that should be routed to V3.5 may be routed to V4.0 or V5.0.

In the event of problems while running coexistence of plug-ins, IBM recommends that you run additional tests with one plug-in temporarily disabled. This helps to narrow down which plug-in is causing the problem. Usually these problems are due to incorrectly configured URI and VirtualHost mapping within the WebSphere plug-in configuration file(s).

Additional useful information regarding WebSphere plug-in coexistence configurations can be found on the WebSphere Infocenter Web site:

http://www-3.ibm.com/software/webservers/appserv/infocenter.html

Conclusion
This document should be used as a guideline for configuring V3.5 and V4.0 or V5.0 plug-in coexistence using a common web server.

This document does not address the topic of configuring plug-in coexistence for three versions of WebSphere Application Server, such as V3.5, V4.0 and V5.0. See Technote #1113774 for information on this topic.

Plug_in/swg21113774.html
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Plug-in
Operating system(s): Windows
Software version: 5.1
Software edition:
Reference #: 1145706
IBM Group: Software Group
Modified date: Sep 16, 2004