Problem with memory leaks

[Former Member]

Hello, dear SAP WAS experts.

We are experiencing the following problem with J2EE app running in SAP WAS 6.40 which has made us puzzle for quite some time already.

When put under a stress the allocated memory size gradually grows until the application goes out of memory and restarts. When not stressed, the application doesn't go out of memory as quickly but still eventually does.

The application uses thin 9.2.0.4 Oracle JDBC driver to access the database.

The application also uses JMS for messaging, JNDI for keeping some cluster-wide naming.

There is some XML parsing happening for which DOM and SAX factories provided by SAP WAS are used.

The application uses the standard memory setting suggested by SAP WAS install:

-Xms128m -XX:NewSize=32m -XX:MaxNewSize=64m -XX:NewRatio=3 -XX:MaxPermSize=128m -XX:+DisableExplicitGC

We tried max heap size from 256M to 1G with the same result. When memory reaches certain level, CPU spikes at 100% every second - apparently due to GC trying to free some memory.

It runs on two platforms Windows 2000 professional and HP-UX. The problem appears on both.

At first we suspected there were memory leaks in the app. However, when run under a different application server - Oracle 9i for instance, no leaks were found.

We also separately load tested JMS messaging - no problem found there as well.

The problem clearly exhibits itself if there is a lot of database access happening with varying queries and/or a lot of XML parsing. However, I couldn't make it go out of memory when running 3-4 queries in a tight loop though or parsing the same file 100000 times.

I know it's hard to tell without seeing the code, but is there anything you could suggest - I would really appreciate.

By the way do you know if there is a way to reduce size of the prepared statement cache for JDBC, or is it totally up to the JDBC driver? The reason I am asking is that we saw a while ago a similar memory issue in Oracle's app server which was solved by reducing the prepared statement cache size.

Thanks a lot for you time and help.

Regards,

-Yuri Sokolovski

[Former Member]

Which Oracle JDBC driver do you use? - Thin or OCI. The OCI driver is not pure java and uses platform dependent libaries (.so on unix, .dll on windows).

These platform dependent drivers are said to produce memory leaks as unclean memory management is involved (a typical C and C++ problem).

My advice: Find out if you really need the OCI driver and switch to the thin driver. Your JDBC connect URL tells you which driver is in use.

[Former Member]

Hi, Thanks for fast reply.

No, we're using thin JDBC for Oracle 9.2.0.4 for JDK 1.4.

Thanks again.

[Former Member]

Hi, All.

We found what the problem was.

The application leaked SAP JDBC statement wrapper objects.

The actual Oracle statement handle was closed with the result set:

resultSet.getStatement().close();

However, it didn't close the SAP wrapper object.

So we solved it by always closing the actual JDBC statement object obtained from connection.prepareStatement or connection.createStatement.

The reason we never had leaks for other application servers (Oracle 9i, WebLogic 8.1) is probably they are able to handle this situation more gracefully (i.e. return the container wrapper statement object on resultSet.getStatement()).

Regards and thanks to all.

Yuri Sokolovski,

NRX Global

SCEA