WebSphere Plug-in basics 2

Modifying and reloading the plug-in file

When new applications are installed in WebSphere Application Server, or when existing ones are modified, it may be necessary to update plugin-cfg.xml. The plug-in configuration file can be modified in the following ways:

• ·         Use the Web-based administration user interface (webui).
• ·         Run the command line utility GenPluginCfg.bat2.
• ·         Manually edit plugin-cfg.xml in a text editor3.

If the Web server resides on a machine other than the application server machine, the plug-in file needs to be copied or FTP’d from the application server  machine to the Web server machine. If plugin-cfg.xml is updated, it can automatically be reloaded by the plug-in without requiring a restart of the Web server. By default, the plug-in attempts to reload the plug-in configuration file every 60 seconds. The plug-in does this by checking the timestamp of plugin-cfg.xml, and if the timestamp has changed since the previous check, it reloads it.

The default poll rate is 60 seconds and should be sufficient for most applications. However, if you need to change it, insert the RefreshInterval attribute into the Config tag of plugin-cfg.xml. Please note that this integer represents seconds, so in this example, we are reloading the plug-in file every 5 minutes:

<?xml version="1.0"?>

<Config RefreshInterval=”300”>

<Log LogLevel="Warn" Name=

"D:\WebSphere\AppServer/logs/http_plugin.log"/>

<Property Name="ESIEnable" Value="false"/>

<Property Name="ESIMaxCacheSize" Value="1024"/>

RetryInterval

If the plug-in is unable to send a request to a particular application server, it will mark that application server as being unreachable and will redirect that request (and all future requests) to the next clone in that ServerCluster. This failure/redirection step will cause a delayed response to the first request which detects the failed application server. If session sharing is enabled (using either persistence or in-memory session replication), the new clone will pick up the session information, and there will be no loss of session. But if the session is not being shared, it will cause the session information to be lost, and the user will have to create a new session. The browser gets an HTTP error 500 if every clone in the ServerCluster is down. The plug-in will not send future requests to the failed application server for a period specified by the RetryInterval attribute on the ServerCluster tag in plugin-cfg.xml. The unit of the RetryInterval is in seconds. It is modified as shown below:

<ServerCluster Name="server1_Cluster" RetryInterval=”10”>

<Server Name="server1">

<Transport Hostname="localhost" Port="9080" Protocol="http"/>

The default value is 60 seconds, which should work well for most applications. Depending on your unique needs, you may consider increasing or decreasing that value for your environment. As a general rule, you don’t want to set a RetryInterval value too high, because then the failed clone will be out of loop for that much longer. In case of a heavily loaded application, this may overburden the remaining clones. However, with a high RetryInterval value, you will send a request to the failed clone less often, resulting in fewer response delays caused by the clone that is down.

Retrying the application server when it is up again

The plug-in retries sending a request to a downed application server every <RetryInterval> seconds. If the failed application server has recovered in that time, then it is marked as being “up” once again. Only new requests will be forwarded to this application server, and requests currently associated with other clones in this cluster will continue to go only to the old ones.

ConnectionIOTimeout

This is the maximum time (in seconds) to wait when trying to read data during the request. The default value is 5 seconds. This timeout determines how long to wait to read at least one byte of data. The default value will work fine for most environments.

ConnectionKeepAliveTimeout

This is the maximum time to wait for the next request on a KeepAlive connection. The default value is 5 seconds. If the next request on this KeepAlive connection is not received within this time, the connection will be closed. This value should be set after studying the typical load on the application server. This custom property is ignored if MaxKeepAliveConnections is equal to zero.

ServerIOTimeout means "how long should the plug-in wait for a response from the application". After the socket is opened, the plug-in sends the request to the Application Server. The application processes the request and a response is sent back to the client, through the plug-in. How long should that take? What is reasonable, based on the application? There is no single correct answer here. It depends on the application. If the application is very quick to respond, then you can use a lower value for ServerIOTimeout. I usually recommend 60 seconds for this. However, if the application requires more time to process the request (maybe to retrieve data from a database), then you should use a higher number for ServerIOTimeout, like 180 seconds, or more. Using a value of 0 means that the plug-in will NOT time-out the request. This is often NOT ideal. It is recommended to start with 60 seconds and adjust up or down as necessary. A positive value means that the plug-in will NOT mark the appserver down after a ServerIOTimeout pops. So, if you want the plug-in to continue sending requests to the timed-out appserver, use a positive value. On the other hand, a negative value means that the plug-in WILL mark the appserver down after a ServerIOTimeout pops. So, if you want the plug-in to immediately mark the appserver down and fail-over to another appserver in the same cluster, use a negative value.

LoadBalanceWeight is a starting "weight". The value is dynamically changed by the plug-in during runtime. The "weight" of a server (or clone) is lowered each time a request is assigned to that clone. When all weights for all servers drop to 0 or below, the plug-in has to readjust all of the weights so that they are above 0. Using a starting value of only 2 (default), means that the weights will get to 0 very quickly and the plug-in will constantly be readjusting the weights. Therefore, It is recommended to start with a higher LoadBalanceWeight. The IBM WebSphere Application Server administrative console will allow a value up to 20 for this. However, it is certainly possible to manually edit the plugin-cfg.xml file and specify some other value for LoadBalanceWeight that is higher than 20.