United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4771005 PIORB is slow when ClientRequestInterceptor is used
JDK-4771005 : PIORB is slow when ClientRequestInterceptor is used

Details
Type:
Bug
Submit Date:
2002-10-30
Status:
Closed
Updated Date:
2003-01-24
Project Name:
JDK
Resolved Date:
2004-12-10
Component:
other-libs
OS:
solaris_8,solaris_2.6
Sub-Component:
corba:idl
CPU:
sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
j2ee1.3.1-fcs,7.0se,1.4.1
Fixed Versions:
1.4.1 (02)

Related Reports
Backport:
Backport:

Sub Tasks

Description
Problem Description:
-----------------------
We are seeing extremely poor performance from the PIORB when client 
interceptors are installed. I have a test which does a void-void ping on a 
remote server. On the ORB without any interceptors I can do about 100000 
invokes in 70s. If I install a null interceptor (every method does nothing) 
this drops to 100000 invokes in 200s. Stranger still the results get worse 
the longer I run the test for. So 10000 invokes complete in 10s and then 
increases non-linearly - 20000/21s, 30000/35s, 40000/50s ...

Attached is a testcase. You will need an appserver to deploy the RMI object 
on (or you may be able to do it with the JDK orb. It is dependent on your 
server being quick enough to sustain the load.

unjar and build. Deploy PingerImpl in your appserver.

To run you need to do:

java -classpath . piorbtest.PIORBTest <url> 100000

where url is the address of your CosNaming service that is hosting the RMI 
object.

The test runs for me in 246s. If I remove the call to 
add_client_request_interceptor it runs in 76s. Note that I am not doing 
set_slot or anything like that.

*****************************************************************************

###@###.### 2002-12-10

Fix verified OK.

With build - j2sdk-1_4_2-beta-bin-b09-solaris-sparcv9-04_dec_2002
With test  - tests/performance/interceptors

*****************************************************************************

                                    

Comments
SUGGESTED FIX

For the application server portion of the fix, here's the relevant information:

The fix was limited to a single file com/sun/corba/ee/internal/Interceptors/SlotTableStack.java.
One could check out the diffs in Bonsai at http://cvsync.red.iplanet.com/bonsai/cvsqueryform.cgi.
Or
Do the diffs manually by using (cvs branch name:  iASDev_Branch) :
cvs diff -r 1.1.2.3 -r 1.1.2.4 SlotTableStack.java

I am attaching the review template and the diffs again for anyone who wants to see:

Module: orb


Review Template
---------------

Bug # : 4771005

Synopsys :orb: PIORB is slow when ClientRequestInterceptor is used

CTS Impact : None

Perf Impact : Yes

UI Impact : None.

Doc Impact : None

Brief description :  (From Harold Carr's mail explaining the fix that he made)

SlotTableStack.pushSlotTable uses List.add which
causes existing elements to get shifted "right" causing the table to grow
without bounds and to hold onto data in those unbounded slots.
Also, popSlotTable did not null unused slots so any data they held
would be released. This behavior has been corrected.

Test Case:

This has been tested by the ORB SQE team. The details of the tests
can be got from the bug report and from the SQE team. No new tests
need to be written to test this on the appserver.

Diffs:
Index: SlotTableStack.java
===================================================================
RCS file:
/m/src/iplanet/ias/server/src/java/com/sun/corba/ee/internal/Interceptors/SlotTableStack.java,v
retrieving revision 1.1.2.3
diff -r1.1.2.3 SlotTableStack.java
112c112,122
<         tableContainer.add( currentIndex, table );
---
>         // NOTE: Very important not to always "add" - otherwise a memory leak.
>         if (currentIndex == tableContainer.size()) {
>             // Add will cause the table to grow.
>             tableContainer.add( currentIndex, table );
>         } else if (currentIndex > tableContainer.size()) {
>             throw new org.omg.CORBA.INTERNAL("currentIndex > tableContainer.size(): " +
>                                currentIndex + " > " + tableContainer.size());
>         } else {
>             // Set will override unused slots.
>             tableContainer.set( currentIndex, table );
>         }
115a126
>
135a147
>         tableContainer.set( currentIndex, null ); // Do not leak memory.

                                     
2004-06-11
EVALUATION

We have measured the impact of PI in the past and did not see this magnitude of slowdown. 


###@###.### 2002-11-19  Using a test produced by Sony I can reproduce the slowdown and see a memory leak.  I have found and fixed the problem.


###@###.### 2002-12-20 This is a problem in both the Mantis code
base and in the SunOne Application Server code base.  This fix plugs a memory
leak which occurs in the ORB of the S1AS7.0 container and needs to be fixed
in an update release there as well.
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.1_02
mantis

FIXED IN:
1.4.1_02
mantis-beta

INTEGRATED IN:
1.4.1_02
mantis-b09
mantis-beta

VERIFIED IN:
mantis-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together