PQ67128: MEMORY LEAK WHEN DOMINO CLIENT USING NCSOW.JAR REPEATEDLY CALLS ORB.INIT(). ORB.SHUTDOWN() CLOSES THREADS BUT JBROKER STILL LEAK

 A fix is available

4.0.5: WebSphere Application Server Version 4.0 Fix Pack 5 (Version 4.0.5)



APAR status
Closed as program error.

Error description
The client is either WAS35 or WAS400 with a servlet running on
top of Domino client ncsow.jar and the server is either Domino 5
or 6. When a user invokes a servlet via a browser, this servlet
will call Domino's ncsow.jar which in turn calls for ORB.init().
Pressing the refresh button or by accessing the same servlet
with a new browser window with the same URL will cause the
WebSphere App Server to create a new ORB instance every single
time.  The existing ORBs dont go away and new ORBs are being
generated causing WebSphere to run out of memory.
.
A new ORB.Shutdown() method has been succesfully implemented
for the ncsow.jar to call at the end of each executiuon cycle
closing the listener threads and associated socket objects,
nevertheless, a slow memory leak in the JBroker component is
still experienced.
.
The memory leaking is happening in the following place:
com.ibm.ejs.jts.jts.JBrokerSupport.add() methods
Local fix
n/a
Problem summary
****************************************************************
* USERS AFFECTED: All WebSphere Application Server users of    *
*                 Domino client within WAS server.             *
****************************************************************
* PROBLEM DESCRIPTION: When using remote access by NCSOW.jar   *
*                      between WebSphere Servlet/JSP and       *
*                      Domino Server, WebSphere's JavaIDL      *
*                      listener threads are not cleaned up     *
*                      after each completion of the servlet    *
*                      and causes the memory leak in the       *
*                      WebSphere Application Server.           *
*                                                              *
****************************************************************
* RECOMMENDATION:                                              *
****************************************************************
When using remote access by NCSOW.jar between WebSphere
Servlet/JSP and Domino Server, WebSphere's JavaIDL listener
threads are not cleaned up after each completion of the
servlet and causes the memory leak in the WebSphere
Application Server. The root cause is the listener threads
have not released its resources back to the current ORB object
while the ORB object is awaiting and depending on these
listeners' termination before making a completed stop and
cleaning up of itself.

When user re-invokes servlet by refreshing the browser each
time, a new ORB object and JavaIDL listeners object are being
created; and at the same moment, the current ORB and JavaIDL
listeners are still sitting there expecting a client's
incoming call. As a result, old and existing ORB objects and
JavaIDL listener threads objects were not being removed and
new ORB objects and JavaIDL listener thread objects are being
created. These old and new ORB and JavaIDL listener objects
will eventually use up all of the available memory and the JVM
will throw an out of memory exception when it is full.
Problem conclusion
Created a new property, com.ibm.CORBA.noPlugins with possible
values of true or false, to allow the servlet to instantiate
ORB objects without any ORB plugins. By doing so, we also
provide a servlet template for customer to follow. Basically,
this servlet is not a J2EE servlet, but it follows the CORBA
programming model instead. In the servlet, we allow servlet to
create an instance of ORB object by calling ORB.init() and
destroy the same instance of ORB object by calling
ORB.shutdown(false) on each request. A sample copy of the
servlet had been provided in the readme file within the APAR
directory.
Temporary fix Comments
APAR information
APAR number PQ67128
Reported component name WEBSPHERE AES N
Reported component ID 5630A2301
Reported release 400
Status CLOSED PER
PE NoPE
HIPER NoHIPER
Submitted date 2002-10-10
Closed date 2002-11-12
Last modified date 2003-03-14

APAR is sysrouted FROM one or more of the following:

APAR is sysrouted TO one or more of the following:
PQ72092

Modules/Macros
ORB          

SRLS

Fix information
Fixed component name WEBSPHERE AES N
Fixed component ID 5630A2301

Applicable component levels
R400 PSY    UP


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > General
Operating system(s):
Software version: 400
Software edition:
Reference #: PQ67128
IBM Group: Software Group
Modified date: Mar 14, 2003