APAR status |
Closed as program error.
| Error description
If the POST data for a HTTP request can not be read by the
webserver/plugins, the thread servicing that request will hang
there forever. If enough of these threads build up, the
webserver will no longer be able to serve (and in the IHS case,
accept) new HTTP connections. This could be handled a little
more gracefully if timeouts were enabled for reads on POST
data. This won't make the problem go away - usually the
problem is caused by network problems ( not always on networks
that the customer controls, as a network problem anywhere
between the web browser and the web server can do it ), or by
requests that specify a content length that is greater than the
actual amount of data posted. In the second case, it's imperativ
the client is fixed - once again, the timeout solution only impr
our handling - if you throw enough bad connections at it fast
enough, it is still possible for it to fail. Also, a version of
for this was included in PQ51372 - this APAR should be preferred
for customers who just need the IHS/iPlanet timeout.PQ51372 is a dependency nightmare, and should be
avoided when possible.
This APAR supercedes PQ46910 and PQ51372. Local fixProblem summary
****************************************************************
* USERS AFFECTED: WebSphere Application Server 3.5 users of *
* IHS. *
****************************************************************
* PROBLEM DESCRIPTION: The timeout directive in the ** HTTPD.CONF wasn't being honored by *
* requests handled by the WAS plugins. *
* Network problems could halt servlet *
* processing indefinitely once enough of *
* the webserver threads were blocking on *
* IO between the webserver and the web *
* browser due to the network problems. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
The fix was to make the plugins honor the timeout directive.
With this fix applied, the plugins will only block on
IO requests for as long as the Timeout directive is set
in the httpd.conf. This can't prevent servlet processing
from halting in the worst case scenario network problems, but
it does allow us to weather common types of network problems
much more gracefully. Problem conclusion
The timeout has been enabled, and positive feedback has been
received on the fix. Temporary fixComments
This actually went into fixtest a month ago.
APAR information | APAR number | PQ57425 | Reported component name | WAS ADVANCED AI | Reported component ID | 5648C8400 | Reported release | 350 | Status | CLOSED PER | PE | NoPE | HIPER | NoHIPER | Submitted date | 2002-02-04 | Closed date | 2002-03-27 | Last modified date | 2003-01-02 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:APAR is sysrouted FROM one or more of the following:APAR is sysrout
Modules/Macros ed TO one or more of the following:Modules/Macros
|
Fix information |
Fixed component name | WAS ADVANCED AI | Fixed component ID | 5648C8400 |
Applicable component levels | R350 PSY | UP |
|