WAS (WebSphere) Plugin Configuration XML (plugin-cfg.xml) Parameters – ConnectTimeout and ServerIOTimeout

In this link, you can find out all the available parameters that you can modified / set in plugin-cfg.xml. The 2 parameters that I am interested in, which is related to how long the plugin connects to WebSphere Application Server: ConnectTimeout and ServerIOTimeout.

ConnectTimeout identifies how long (in seconds) the plugin will wait to get connect to WebSphere Application Server (WAS). If the plugin waits longer than the value, it will mark the server unavailable.

By default (without the parameter set in the plugin-cfg.xml) or setting the value to 0, it represents a blocking connect, that is, the thread will keep waiting to obtain a connection until the operating system time out the request.
ServerIOTimeout identifies how long (in seconds) the plugin will wait for the server to response to the request. If the plugin waits longer than the value before the response is completed, it will time out.

By default, the plugin uses blocked I/O. So basically it will block wait until TCP connection times out.

Other comments above two parameters:

Comment by Jim

July 31, 2008 @ 4:39 am

Hi,
I am writing you exactly 1 year after you published this post :-)
I was trying to find out the differences between ConnectTimeOut and ServerIOTimeOut and reached here.
What I understand from your post is that ServerIOTimeOut is the number of seconds the plugin module waits before getting a response – calculated from the moment it started attempting to connect.
If I set ConnectTimeOut to 10 seconds and ServerIOTimeOut to 20 seconds, and if the app server is not responding, then the plugin will timeout the connection after 10 seconds. In this case, what is the significance of ServerIOTimeOut parameter?
Thanks in advance.
Jim

Comment by 

July 31, 2008 @ 7:06 am

Hello Jim. My understanding is that the 2 timeouts are tracking 2 different states. ConnectTimeOut measures the time it takes the plugin to connect to the application server, whereas the ServerIOTimeOut measures the time it takes for the server to respond to the plugin AFTER successfully connected to the plugin.
So in your example, if your plugin cannot connect to the app server in 10 seconds, it will time out (by ConnectTimeOut). After the plugin can successfully connect to the app server, if the request cannot be completed in 20 seconds, then it will timeout (by ServerIOTimeOut)

Hope this help.

Request routing using plug-in

Request routing using plug-in


The Web Server plug-in uses an XML configuration file to determine whether a request is for the Web Server of the application server

. When a request reaches the Web Server, the URL is compared to those managed by the plug-in. IF a match is found, the plug-in configuration file contains the information needed to forward the request to the web container using the web container inbound chain.

For example lets say you make a request to http://localhost/sessionaffinity/SessionAffinityServlet URL, so the Web Server Plugin will check the /sessionaffinity URL to find out how it is should be handled, It will check if there is matching UriGroup element in plugin-cfg.xml

<UriGroup Name="default_host_cluster1_URIs">

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/HelloWorldWeb/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/NameSpaceWeb/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/dynasession/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/webappext/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/dynacachereplication/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/HelloWorldPortlet/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/HelloWorldPortlet2/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/helloworldportlet/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/cachemonitor/*"/>

<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/sessionaffinity/*"/>

</UriGroup>


In this case it knows that the /sessionaffinity/* URL is for dynamic content, so the next part is how to route it to correct server. It will read value of Name attribute for the UriGroup which is default_host_cluster1_URIs, and name of the cluster is cluster1. It will use these values find out virtual host and cluster

<Route ServerCluster="cluster1" UriGroup="default_host_cluster1_URIs" VirtualHostGroup="default_host"/>

<VirtualHostGroup Name="default_host">

<VirtualHost Name="*:9080"/>

<VirtualHost Name="*:80"/>

<VirtualHost Name="*:9443"/>

<VirtualHost Name="*:5060"/>

<VirtualHost Name="*:5061"/>

<VirtualHost Name="*:443"/>

<VirtualHost Name="*:9081"/>

<VirtualHost Name="*:9082"/>

</VirtualHostGroup>

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" IgnoreAffinityRequests="true" LoadBalance="Round Robin" Name="cluster1" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">

<Server CloneID="14dtuu8g3" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server2" ServerIOTimeout="0" WaitForContinue="false">

<Transport Hostname="dmgr.webspherenotes.com" Port="9081" Protocol="http"/>

<Transport Hostname="dmgr.webspherenotes.com" Port="9444" Protocol="https">

<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>

<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>

</Transport>

</Server>

<Server CloneID="14dtuueci" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="dmgrNode01_server4" ServerIOTimeout="0" WaitForContinue="false">

<Transport Hostname="dmgr.webspherenotes.com" Port="9082" Protocol="http"/>

<Transport Hostname="dmgr.webspherenotes.com" Port="9445" Protocol="https">

<Property Name="keyring" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.kdb"/>

<Property Name="stashfile" Value="C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-key.sth"/>

</Transport>

</Server>

<PrimaryServers>

<Server Name="dmgrNode01_server2"/>

<Server Name="dmgrNode01_server4"/>

</PrimaryServers>

</ServerCluster>

It knows that the cluster1 has two servers dmgrNode01_server2 and dmgrNode01_server4 and from the cluster definition it can find out the http and https port and then forward request to either of the server. The cluster definition also says that the Load balancing

algorithm is Round robin

#####################################################################

Plugin configuration file

Plugin configuration file


The plug-in configuration file (plugin-cfg.xml) contains routing information for all applications mapped to the Web server. This file is read by a binary plug-in module loaded in the Web server. An example of a binary plug-in module is the mod_ibm_app_server_http.dll file for IBM HTTP Server on the Windows platform. This is how the location of plugin-cfg.xml is defined in httpd.conf file


LoadModule was_ap20_module "C:\Cert\HTTPServer\Plugins\bin\32bits\mod_was_ap20_http.dll"

WebSpherePluginConfig "C:\Cert\HTTPServer\Plugins\config\webserver1\plugin-cfg.xml"

The binary plug-in module does not change. However, the plug-in configuration file for the binary module needs to be regenerated and propagated to the Web server whenever a change is made to the configuration of applications mapped to the Web server. The binary module reads the XML file to adjust settings and to locate deployed applications for the Web server.

This is how the sample plugin-cfg.xml file on my machine looks like


Important Note When the plug-in configuration file is generated, it does not include admin_host in the list of virtual hosts.

Regenerating plugin configuration file

Regenerating plugin configuration file


The plug-in configuration file (i.e. plugin-cfg.xml), has information on how to route a request from browser to the correct application on the application server. So you will have to regenerate this file in case of there is any changes in websphere application server that affects how the request is routed from the web server to the application server.

The plugin-cfg.xml should be regenerated in following situations

•Installing or removing application

•Creating or changing virtual host

•Creating or changing cluster

•Creating a new server

•Modifying HTTP transport settings

You can manually regenerate plugin using either the GetPluginCfg command, or using the WAS Admin console, or you can also setup the plug-in properties of the web server to enable automatic generation of the file, whenever relevant changes are made

Manually regenerating plugin-cfg.xml

Manually regenerating plugin-cfg.xml


You can regenerate the plugin-cfg.xml file manually in two ways

Using WAS Admin Console
Login into the WAS Admin console, select the web server for which you want to regenerate plugin and click on Generate Plug-in button. The new plugin-cfg.xml file will be created in the config directory of the web server like this

Using GenPluginCfg command

You can also regenerate plugin using the GenPluginCfg command line tool by going to dmgr_profile_home/bin directory and executing GenPluginCfg command like this

##################################################################

Automatic regeneation of plugin-cfg.xml

Automatic regeneation of plugin-cfg.xml


The Web server plug-in configuration service by default regenerates the

plugin-cfg.xml file automatically. You can check the setting from WAS Admin console

When selected, the Web server plug-in configuration service automatically generates the plug-in configuration file whenever the Web server environment changes. 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.

Whenever a virtual host definition is updated, the plug-in configuration file

is automatically regenerated for all of the Web servers.

In my local environment i tried installing a new web application and after installation was completed i checked the plugin-cfg.xml file and it had a entry for newly installed application. Also i could see this in my DMGR's SystemOut.log file

[9/14/09 21:29:23:290 PDT] 00000052 DeploymentMan A ADMS0208I: The configuration synchronization complete for cell.

[9/14/09 21:29:29:540 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver2/plugin-cfg.xml.

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.

[9/14/09 21:29:29:540 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver2.

[9/14/09 21:29:29:556 PDT] 00000048 SystemOut O PLGC0051I: Plug-in configuration file generation started for the Web server dmgrCell01.dmgrNode01.webserver1.

[9/14/09 21:29:30:150 PDT] 00000048 FileRepositor A ADMR0016I: User defaultWIMFileBasedRealm/server:dmgrCell01_dmgrCellManager01_dmgr modified document cells/dmgrCell01/nodes/dmgrNode01/servers/webserver1/plugin-cfg.xml.

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0005I: Plug-in configuration file = C:\Cert\WebSphere\AppServer\profiles\Dmgr01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.

[9/14/09 21:29:30:150 PDT] 00000048 SystemOut O PLGC0052I: Plug-in configuration file generation is complete for the Web server dmgrCell01.dmgrNode01.webserver1.

[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O

[9/14/09 21:29:56:775 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver2\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins\config\webserver2\plugin-cfg.xml on the Web server computer.

[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O

[9/14/09 21:29:56:775 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.webserver2.

[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O

[9/14/09 21:29:56:853 PDT] 00000055 SystemOut O PLGC0062I: The plug-in configuration file is propagated from C:\Cert\WebSphere\AppServer\profiles\AppSrv01\config\cells\dmgrCell01\nodes\dmgrNode01\servers\webserver1\plugin-cfg.xml to C:\Cert\HTTPServer\Plugins/config/webserver1/plugin-cfg.xml on the Web server computer.

[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O

[9/14/09 21:29:56:869 PDT] 0000001f SystemOut O PLGC0048I: The propagation of the plug-in configuration file is complete for the Web server dmgrCell01.dmgrNode01.


####################################################################

Manually propagating the plug-in configuration file

Manually propagating the plug-in configuration file


After a plug-in configuration file is regenerated, it needs to be propagated to the Web server. The configuration service can automatically propagate the plugin-cfg.xml file to a Web server machine if it is configured on a managed node, and to an IBM HTTP Server if it is configured on an unmanaged node. For other scenarios, you must manually copy the file to the Web server machines. You can manually propagate the file by copying it from the application server machine to the Web server machine, or you can do it from the administrative console.

I tried propagating the plugin-cfg.xml file manually using the WAS Admin console by selecting the server and clicking on Propageate Plug-in button

Important: The Web server binary plug-in module checks for a new configuration file every 60 seconds. You can wait for the plug-in to find the changes, or you can restart the Web sever to invoke the changes immediately

Automatically propagating the plugin-cfg.xml

Automatically propagating the plugin-cfg.xml


The Web server plug-in configuration service by default propagates the plugin-cfg.xml file automatically

In my local environment both automatic regeneration and propagation of plugin is truned on so when i install application it automatically regenerates the plugin-cfg.xml and then copies it to the C:\Cert\HTTPServer\Plugins/config/webserver1 directory
 
##############################################################################

How can we configure Remote Plugin?

This is the procedure


Machine A: WAS

Machine B: IHS

Thumb Rule: Install Plugins on IHS Machine and propagrate them to WAS.

Procedure

Machine A : Install WAS.

Machine B: Install IHS

Machine B : Install Plugins: In the installation process, you have to select remote WAS, and name for ur webserverconfig, say webserver1. After installation, in the IHS_INST/conf/httpd.conf check for IBM Module entry and Plugin installation paths

Goto the plugin installation path/bin

Check for configurewebserver1.sh/bat

Now,

Copy that file, configurewebserver1.sh/bat to WAS box, that is Machine A. The file contains this info.

./wsadmin.sh -f configureWebserverDefinition.jacl webserver1 IHS '/software/IBM/IHS' '

/software/IBM/IHS/conf/httpd.conf' 7700 MAP_ALL '/software/IBM/Plugins' unmanage

d webserver1 hostname solaris

(This is an example, 7700 is port number.)

If you already have enabled global security on WAS, you need to add -username adminusername and -password hispassword at the end of the above script.

Then run the script.

Which creates a WebServer definition in the AppServer.

U need to configure WAS to remote admin WebServer

Merging plugin-cfg.xml files from multiple nodes

Problem(Abstract)
Merging plugin-cfg.xml files from multiple nodes for releases of IBM® WebSphere® Application Server version 5 and version 6.



Resolving the problem
Merging two plugin-cfg.xml files

1.The tag is the root element in the plugin-cfg.xml file. There should be only one element in the merged file.


2.Copy the element from any of the two merging files, and modify the Name, if required.


3.Copy all the elements from both the files. The VirtualHostGroup name must be unique; if the names are not unique, prepend the node name to the VirtualHostGroup name to make it unique.

When serving a request, the plug-in searches for the VirtualHost and URI, so the combination of these must be unique. If it is not, you receive unexpected results. As a precautionary step, make sure that the VirtualHost name is unique. Avoid having an asterisk ( * ) in the virtual host name; instead, explicitly specify the server name and port number.


4.Copy all elements from both the files. Normally they are unique because the host name is included in the name; however, make the names unique if necessary.


5.Server Name must be unique across all clusters. From WebSphere Application Server version 5.0.1 or higher, host or node name is included in server name. If you are at version 5.0, then you might have to prepend the host name to the server name to make it unique.


6.In the element, the properties keyring and stashfile should use the same location for all the Application Servers in the merged file.


7.Copy all the elements from both nodes. Normally these are unique because a server cluster name is included; however, make the names unique if necessary.


8.Copy all the elements and apply any changes that you have made to the names of VirtualHostGroup, ServerCluster or URIGroup.


9.Make sure that resources are unambiguously specified. Especially when merging two servers containing applications with similar context-root. You may want to consider utilizing virtual host aliases in Administrative Console to unambiguously route the requests to specific application server.


10.Make sure that the Web server points to the new plugin-cfg.xml file.