Notes that could help, the below was summarized over digging all around web to overcome a issue that I was troubleshooting, Thought it was useful to post.
* The issue is with the default setting of ServerIOTimeout property in the IHS Plugin component which needed modification and not on IHS instance
* The changes/modification needs manually editing files as this property is not visible and cannot be modified from Admin Console ( Added in next release of WebSphere/IHS (8.0) )
A breif synopsis and info regarding ServerIOTimeout from IBM Technotes ( IBM Tech Note URLs are provided below for further reference)
ServerIOTimeout
Enables the plug-in to set a timeout value, in seconds, for sending requests to and reading responses from the application server. (Further clarification: This is not from client/browser to IHS (Compression Server) but from Plugin component to WebSphere JVM)
If you set the ServerIOTimeout attribute to a positive value, this attempt to contact the server ends when the timeout occurs. However, the server is not considered unavailable and future requests are still sent to the server on which the unavailable timeout occurred.
If you set the ServerIOTimeout attribute to a negative value, the server is considered unavailable whenever a timeout occurs, and no future requests are sent to the server on which the timeout occurred.
If a value is not set for the ServerIOTimeout attribute, the plug-in, by default, uses blocked I/O to write requests to and read responses from the application server, and does not time out the TCP connection. For example, you might specify the following setting:
nov-2011 update
For example, you might specify the following setting:
<Server Name="server1" ServerIOTimeout=300>In this situation, if an application server stops responding to requests, the plug-in waits 300 seconds (5 minutes) before timing out the TCP connection. Setting the ServerIOTimeout attribute to a reasonable value enables the plug-in to timeout the connection sooner, and transfer requests to another application server when possible.
When selecting a value for this attribute, remember that sometimes it might take several minutes for an application server to process a request. Setting the value of the ServerIOTimeout attribute too low might cause the plug-in to send a false server error response to the client.
The default value for this property is 60.
jul2011 update
Avoid trouble: The ServerIOTimeout limits the amount of time the plug-in waits for each individual read or write operation to return. ServerIOTimeout does not represent a timeout for the overall request.
The ServerIOTimeout property is designed to allow requests to time-out instead of waiting indefinitely for a response from the server. In Versions 6.1 and earlier, the serveriotimeout property defaults to 0, which indicates that there is no time limit for requests. This value is not recommended because if the a server never responds, the resources involved in this request might never be freed and eventually the resource pool is exhausted. In some cases, the operating system or adapter resources might break the connection because of inactivity but this is not behavior that should be relied on. You will need to determine the appropriate behavior for your environment if you plan to set the ServerIOTimeout property to 0.
If the ServerIOTimeout property is set to 0, do not expect requests to be retried. A request is not retried until the previous connection is broken and, as explained previously, the connection might not get broken. If you need to use the retry capabilities of the plug-in, either set the serveriotimeout property to a non-zero value, use the operating system settings, or use some other non-plug-in mechanism to ensure that you can guarantee that a connection is broken at some predetermined time.
With Version 7.0, the default value of the ServerIOTimeout property is 60 seconds. This might not be the ideal setting for applications running intensive queries or other nontrivial functions. The ServerIOTimeout value will need to be adjusted if you expect requests to take longer than 60 seconds to be served.
The ServerIOTimeout setting is based on how long the server takes to handle a request; not on a particular URI or application. Therefore, when specifying a value for this property, you should allow for the slowest, longest request time, and then add a little more time to handle peak operation situations.
The Use read/write timeout setting on the administrative console corresponds to the ServerIOTimeout attribute in the plugin-cfg.xml file. The default for the setting and the attribute for Version 8 is 900 seconds. For Version 7, the default is 60 seconds. Before Version 7, the default is 0.
Please note: The methods of adding this property described in below tech notes from IBM from Admin Console do not work, this has been tried and tested during this effort ( that is -> Adding custom property to IHS Server via console)
PK26979: INFORMATION CENTER DESCRIPTION OF SERVERIOTIMEOUT IN "WEB SERVERPLUG-IN CONFIGURATION PROPERTIES" PAGE IS INCORRECT
PK76657: APPSERVERPORTPREFERENCE AND SERVERIOTIMEOUT CHANGES ARE NOT BEING PERSISTED TO THE PLUGIN-CFG.XML FILE.
Modifying web server plug-in properties from the WebSphere Application Server administrative console
1 comment:
It says in one of your links that fixpack 7.0.0.3 fixed the issue. PK76657 says was fixed in 2009. Are you saying as of 2013 it still existed? I'm having a problem with a timeout and getting similar results.I don't have root access to modify this file. :(
Post a Comment