PQ76375: GETTING 500 ERRORS OR BLANK SCREENS WHEN ACCESSING WEBSPHERE V4 J2EE SERVER VIA THE ZOS HTTP PLUGIN

 A fix may be available

Obtain the fix for this APAR



APAR status
Closed as program error.

Error description
Customer is using the zOS verison of the HTTP Plugin , used
to maintain session affinity across J2EE servers. This plugin
is configured using the plugin-cfg.xml file.
   The function seems to work correctly. However, if the
customer codes multiple servers in the ServerGroup of the
plugin-cfg.xml and one or more of those servers is down, the
RoundRobin function may fail to route the request to a server
that remains up.
   What should happen is that the PLUGIN should try to route
the request to all the Servers that match in the ServerGroup.
This is what is not happening. The PLUGIN may try to route the
request to the same (down) server multiple times and never
attempt to route to the AVAILABLE server.
   To determine if this APAR addresses your problem:
  1) message "Failed to find a server; all could be down" will
     be found in the PLUGIN trace.
  2) if you review this thread closer, you should see a message
     "Server xxxxxxx is marked down; retry in yy" for the
     servers in the ServerGroup found to be down. If you see
     the server down message for the same server, more than once
     for the same instance of the thread, this APAR should
     resolve your issue.
Local fix Problem summary
****************************************************************
* USERS AFFECTED: All users of WebSphere Application Server    *
*                 version 4.0.1 for z/OS and OS/390.           *
****************************************************************
* PROBLEM DESCRIPTION: The customer gets 500 errors or blank   *
*                      screens when accessing a WebSphere V4   *
*                      J2EE Server via the WebSphere HTTP      *
*                      PlugIn for z/OS and OS/390.             *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
If the customer codes multiple servers in the ServerGroup of
the plugin-cfg.xml and one or more of those servers is down,
the RoundRobin function may fail to route the request to a
server that remains up.  What should happen is that the PlugIn
should try to route the request to all the Servers that match
in the ServerGroup.  The PlugIn may try to route the request to
the same (down) server multiple times and never attempt to
route to the AVAILABLE server.

To determine if this APAR addresses your problem:
  1) Message "Failed to find a server; all could be down" will
     be found in the PlugIn trace.
  2) If you review this thread closer, you should see a message
     "Server xxxxxxx is marked down; retry in yy" for the
servers in the ServerGroup found to be down. If you see
the server down message for the same server, more than once
for the same instance of the thread, this APAR should
resolve your issue.
Problem conclusion
This problem was fixed in Distributed versions of WebSphere
with defect 166715.  This APAR, PQ76375, is being used to
roll into the z/OS HTTP PlugIn all the distributed fixes
for the HTTP PlugIn up to the committed build level
ptf70328.01 plus fixes for the following 5 defects:

  166715 app svr clone is available, but none found to serve
          request
 
PQ76693 Global webcontainer setting REGEN improperly
 
PQ76729 Applications hang due to handling of content length
 
PQ76727 Symptom: COREs while in IBM HTTP Server SSL module
 
PQ77059 PlugIn not doing an exact match for the JSESSIONID

Distributed ptf70328.01 includes fixes for the following
defects, copied from the README file:

 Fix (APAR):  WAS_Plugin_07-23-2003_4.0.X_cumulative_Fix

 Status:  Fix

Release:  4.0.6,4.0.5,4.0.4,4.0.3,4.0.2

 Operating System:  Windows (General),SunOS/Solaris,AIX

 Supersedes Fixes:  WAS_Plugin_01-17-2003_4.0.x_cumulative
WAS_Plugin_03-07-2003_4.0.x_cumulative (*** MINUS *** the
             appserver fixes)
160002  - Authentication fails with Domino WebServer plugin
160939  - Need configuration options to disable the nagle
          algorithm
162288  - Domino plugin fails to load on Solaris when using
          Domino6
PQ67072 - Invalid error number reported on Solaris

PQ69512 - Compatibility flag for virtual host matching

PQ69608 - Failover problem with proxy firewall

PQ70020 - Case sensitivity for cookie names
PQ70037 - POSTs not using keep-alive connections
PQ70292 - Error logged on incomplete POST content

PQ70620 - Virtual host matching is case sensitive

PQ70962 - Wrong status returned for IIS plugin

PQ71167 - Failure when response header exceeds 8k
PQ71223 - Log level change for "Failed to read the first line
          of continued response"

PQ71608 - Plugin marks the only appserver down

PQ72069 - Need configurable option for redirect port source

PQ72257 - IHS/Apache plugin not reading plugin-cfg.xml after
          refresh interval expires

PQ72428 - Flush request header buffer immediately to reduce
          chance of timeout firing

PQ73479 - Add parameter to specify the chunk size for reading
          the response body

PQ74834 - Update mappings for cipher suite names

PQ75936 - Add support to hanlde headers extended over
          multiple lines

PQ75947 - HTTP Plugin fails to load intermittently.
PQ76680 - Add support to limit the number of connections to
          an Application Server

Publication "WebSphere Application Server V4.0.1 for z/OS and
OS/390, Assembling J2EE Applications" will be updated to add
the following Config attribute to Chapter 8, "Properties of
WebSphere plug-ins for Web Servers":
VHostMatchingCompat (zero or one attribute for each Config)
   This attribute decides the port number used for Virtual
   Host matching.

   When this attribute is enabled, matching is done physically,
   by using the port number in which the request was received.
   Otherwise, matching is done logically, by using the port
   number from the host header. Default is false.

   The value can be true or false.

APAR PQ76375 is associated with SERVICE LEVEL W401603 of
WebSphere Application Server version 4.0.1 for z/OS and OS/390.
Temporary fix Comments
APAR information
APAR number PQ76375
Reported component name WEBSPHERE OS/39
Reported component ID 5655A9800
Reported release 401
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2003-07-15
Closed date 2003-10-09
Last modified date 2003-11-02

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:

Modules/Macros
EJSQ4001 EJSQ4002 EJSQ4003 EJSQ4004 EJSQ4005 EJSQ4006
EJSQ4007 EJSQ4008 EJSQ4009 EJSQ4010 EJSQ4011 EJSQ4012
EJSQ4013 EJSQ4014 EJSQ4015 EJSQ4016 EJSQ4017 EJSQ4018
EJSQ4019 EJSQ4020 EJSQ4021 EJSQ4022 EJSQ4023 EJSQ4024
EJSQ4025 EJSQ4026 EJSQ4027 EJSQ4028 EJSQ4029 EJSQ4030
EJSQ4031 EJSQ4032 EJSQ4033 EJSQ4034 EJSXHTTP  

Fix information
Fixed component name WEBSPHERE OS/39
Fixed component ID 5655A9800

Applicable component levels
R401 PSY UQ80970    UP03/10/14 P F310

  Fix is available
Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s):
Software version: 401
Software edition:
Reference #: PQ76375
IBM Group: Software Group
Modified date: Nov 2, 2003