Operating System - HP-UX
1836770 Members
2274 Online
110109 Solutions
New Discussion

Re: Memory Leaking?: Java 1.3/Oracle 9/ UX11

 
Pete Ryecroft_1
New Member

Memory Leaking?: Java 1.3/Oracle 9/ UX11

Hi all - we have a java (1.3) application running against Oracle 9. The application is simple enough in that it takes a flat file and does a load of inserts into the database. It was all working well on Oracle 8.1.7.2. And then we went to Oracle 9 - now the application fails with out of memory errors after it has been running a while (complains that MAXDSIZ is probably too small - it is set to 1GB so seems big enough). I suspect a memory leak; GPM shows that VSS and RSS just keep growing until the application keels over.
We had to set the Oracle shared library path to 'lib32' as the 'lib' (presumably 64 bit) oracle libs would not work (application just failed to start).

So - is this a known problem and is there a solution?
Pete

VERSION INFO AS FOLLOWS

$ java -showversion
java version "1.3.1.08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1.08-021213-15:02)
Java HotSpot(TM) Server VM (build 1.3.1 1.3.1.08-_13_dec_2002_16_12 PA2.0, mixed
mode)

SQL> select * from v$version
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
PL/SQL Release 9.2.0.1.0 - Production
CORE 9.2.0.1.0 Production
TNS for HPUX: Version 9.2.0.1.0 - Production
NLSRTL Version 9.2.0.1.0 - Production

$ uname -a
HP-UX glasto B.11.11 U 9000/800 1771425047 unlimited-user license
4 REPLIES 4
Nicolas Dumeige
Esteemed Contributor

Re: Memory Leaking?: Java 1.3/Oracle 9/ UX11

Hello Peter,

Do you get ORA-04030 ?

Nicolas
All different, all Unix
Steve Steel
Honored Contributor

Re: Memory Leaking?: Java 1.3/Oracle 9/ UX11

Hi

More fault info please

http://www.hp.com/products1/unix/java/?jumpid=go/java

Then

http://www.hp.com/products1/unix/java/infolibrary/bug_info.html


Consider a newer java

Steve Steel
If you want truly to understand something, try to change it. (Kurt Lewin)
Pete Ryecroft_1
New Member

Re: Memory Leaking?: Java 1.3/Oracle 9/ UX11

I upgraded to 1.4 and got the same error, the log file as follows...

Exception java.lang.OutOfMemoryError: requested 32000 bytes for GrET* in /CLO/Co
mponents/JAVA_HOTSPOT/Src/src/share/vm/utilities/growableArray.cpp. Out of swap
space?
Possible causes:
- not enough swap space left, or
- kernel parameter MAXDSIZ is very small.
Out of memory while reading in symbol table of /opt/java1.4/jre/lib/PA_RISC2.0/
server/libjvm.sl
( 0) 0xc84774d8 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 1) 0xc840fc34 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 2) 0xc85c8458 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 3) 0xc838d98c [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 4) 0xc838caf4 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 5) 0xc85c8d10 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 6) 0xc872b508 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 7) 0xc83dbe78 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 8) 0xc83e0bdc [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
( 9) 0xc83e0328 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(10) 0xc83f584c [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(11) 0xc8706eac [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(12) 0xc83ddd1c [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(13) 0xc874fca4 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(14) 0xc874f980 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(15) 0xc874e820 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(16) 0xc874ee38 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(17) 0xc874e5f4 [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(18) 0xc8629e5c [/opt/java1.4/jre/lib/PA_RISC2.0/server/libjvm.sl]
(19) 0xc1ddb2e4 __pthread_body + 0x44 [/usr/lib/libpthread.1]
(20) 0xc1de5574 __pthread_start + 0x14 [/usr/lib/libpthread.1]
Java out of memory messages are marked with pid: 25719 in /var/adm/syslog/syslog
.log.
./run_ods.sh[41]: 25719 Abort

Can't look in syslog - no permissions - will ask sysadmin to do this for me.


Then I changed the SHLIB_PATH to look down the Oracle 'lib' directory instead of 'lib32' and I got this error (which is what I was getting with Java 1.3 as well).

FATAL Error : FAILED: Task has thrown: java.lang.UnsatisfiedLinkError: /icedata/oracle/oui/lib/libocijdbc9.sl: specified file is not a shared library, or a format error was detected.
?at java.lang.ClassLoader$NativeLibrary.load(Native Method)
?at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1585)
?at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1485)
?at java.lang.Runtime.loadLibrary0(Runtime.java:788)
?at java.lang.System.loadLibrary(System.java:834)
?at oracle.jdbc.oci8.OCIDBAccess.logon(OCIDBAccess.java:262)
?at oracle.jdbc.driver.OracleConnection.(OracleConnection.java:346)
?at oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.java:468)
?at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:314)
?at java.sql.DriverManager.getConnection(DriverManager.java:512)
?at java.sql.DriverManager.getConnection(DriverManager.java:171)
?at com.hp.sapods.db.DBAccess.connect(DBAccess.java:216)
?at com.hp.sapods.db.DBAccess.connectWithRetryWait(DBAccess.java:422)
?at com.hp.sapods.dbtasks.TableExtractTask.ODSConnectWrapper(TableExtractTask.java:206)
?at com.hp.sapods.dbtasks.TableExtractTask.isInitialFullLoad(TableExtractTask.java:1285)
?at com.hp.sapods.dbtasks.TableExtractTask.initiateExtract(TableExtractTask.java:1610)
?at com.hp.sapods.dbtasks.FullExtractTask.execute(FullExtractTask.java:147)
?at com.hp.sapods.core.Task$TaskThread.run(Task.java:924)
?at java.lang.Thread.run(Thread.java:534)

Oracle alert log is error-free.

Cheers
pete

R. Allan Hicks
Trusted Contributor

Re: Memory Leaking?: Java 1.3/Oracle 9/ UX11

I experienced memory leaks in 9i Release 1. Release 2 seemed to clear things up, but since I had no java apps other than oracle's I can't really speak to your problem.

If you are doing inserts from a flat file, you might enjoy looking into one of my favorite features of 9i and that is the external table. I replaced a lot of hard to maintain C code with some simple pl/sql scripts to move data from a flat file to my tables.
"Only he who attempts the absurd is capable of achieving the impossible