PQ44821: CUSTOMER GETTING EXCEPTIONS AND DEADLOCKS UNLESS MAXCONNECTIONS HI ENOUGH TO PREVENT CACHE CLEANING LOGIC EXECUTION FIX IS


APAR

APAR status
Closed as program error.

Error description
After a number of clients connects to a server, the server event
ually hangs/deadlocks in the ORB connection cache cleanup logic.
PD/PSI per DEV Jeff B:
Clients take up at least 2 entries in the connection cache, for
each EJB the client connects to.  Some clients connect to multip
le EJBS.  com.ibm.CORBA.MaxOpenConnections parameter in the ORB
defaults to 240 - this is the # of entries allowed in cache, bef
ore cleanup/removal of oldest used connections.
The current e-fix for this APAR fixes 2 deadlocks that cause the
app servers to quit responding.
PD/PSI per DEV Jeff B:Clients take up at least 2 entries in the connection cache, foreach EJB the client connects to. Some clients connect to multiple EJBS. com.ibm.CORBA.MaxOpenConnections parameter in the ORBdefaults to 240 - this is the # of entries allowed in cache, before cleanup/removal of oldest used connections.The current e-fix for this APAR fixes 2 deadlocks that cause theapp servers to quit responding.
Local fix
Problem summary
NullPointerException in deleteConn() and
CORBA_BAD_PARAM exception
and deadlock conditions in the connection cache cleanup logic
with the high water mark is reached.
Problem conclusion
fixed under 2 zip files, following is a description of what is
being fixed:
(1) Change to log reader thread termination information to the
    ORB trace file instead of the ORB message file.  The
    termination logs are normal in the case when the connection
    cache is being cleaned up when the high water mark is
    reached.
(2) Two deadlock conditions in the connection cache cleanup
    logic with the high water mark is reached.
(3) NullPointerException in deleteConn().  Setting
    MaxOpenConnections high enough would work around this
    problem.
(4) CORBA_BAD_PARAM exception generated by the server and
    received on the client when connections are re-established.
    When the client and server lose the connection between them
    and the connection is restarted by the client, the service
    contexts that are required on the first request over a
    connection are not being sent.
being fixed:(1) Change to log reader thread termination information to theORB trace file instead of the ORB message file. Thetermination logs are normal in the case when the connectioncache is being cleaned up when the high water mark isreached.(2) Two deadlock conditions in the connection cache cleanuplogic with the high water mark is reached.(3) NullPointerException in deleteConn(). SettingMaxOpenConnections high enough would work around thisproblem.(4) CORBA_BAD_PARAM exception generated by the server andreceived on the client when connections are re-established.When the client and server lose the connection between themand the connection is restarted by the client, the servicecontexts that are required on the first request over aconnection are not being sent.
Temporary fix
Comments
APAR information
APAR numberPQ44821
Reported component nameWAS ADVANCED AI
Reported component ID5648C8400
Reported release350
StatusCLOSED PER
PENoPE
HIPERNoHIPER
Submitted date2001-01-05
Closed date2001-01-17
Last modified date2001-01-17

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:


Modules/Macros
ORB
APAR is sysrouted TO one or more of the following:Modules/Macros

Fix information
Fixed component nameWAS ADVANCED AI
Fixed component ID5648C8400

Applicable component levels
R350 PSYUP











Document Information

Product categories: Software, Application Servers, Distributed Application & Web Servers, WebSphere Application Server, General
Software version: 350
Reference #: PQ44821
IBM Group: Software Group
Modified date: 2001-01-17