- 196.9K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.4K Databases
- 221.7K General Database Discussions
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 546 SQLcl
- 4K SQL Developer Data Modeler
- 187.1K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.6K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 443 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 Portuguese
memory leak within their JAVA code
The customer is having a problem with a memory leak within their JAVA application. Something this is not supported by Oracle Support though an SR.
INITIAL FINDING: they didn't use the free() when using the getclobval().
INITIAL SOLUTION: The customer changed their code to add in the free() and this reduced the leak but not all of it. 80-90% of the leak is gone
CURRENT ISSUE: We examined the latest heapdump and it still had the same signature as before, so we asked them to re-exam their code.
They couldn't find anything in the code so the next idea is to trace file JAVA application in hope to locating the memory leak and the location where they need a free() call.
Red Hat Linux
EXIT CRITERIA: Reduce the leak by 99-100%
By examining the headdump from an 126.96.36.199 database, we can see the leak and with the help of Oracle JAVA support initially identified it was related to customer Code NOT using the free() when using the getclobval() function.
---Description provided to the customer in the SR----------------
The Heapdumps from Production confirmed last week was that the Statements that we were focussing on were not triggering leaks from the same areas as what is being seen on your Production environment.
Even if we fix the issue seen on the statements included in the standalone testcase , it is not even a factor on your Production JDBC sessions.
As I had indicated in my earlier update , the Production connection pooled sessions are still showing close to 90% of its leaks in the "koh dur heap d" / "qmxtgCrBufClob" heaps.
Memory allocations from this heap is usually done when using :
a) getclobval() and a corresponding free() is not called.
My preference would be to defer tracing ( being a last resort and a hit-and-miss approach ) and instead work with customer's Development Team to check if a code walkthrough reveals any other instances where getclobVals() are called and the corresponding free() is not called.
If it comes down to tracing , we can pick up a few top sessions and get Memory Snapshots before and after an hour's duration and hopefully we can find the statements of interest.
The customer has NOT been able to locate the getclobval() and corresponding free() mismatch in their code. So they want to attempt to trace their application to pinpoint the segment of code causing the problem.
***** QUESTION for this group ********
We are at the last resort and need to trace to help the customer locate their leak. The JAVA support group pointed us to “How to Troubleshoot Native Memory Leak in Java Applications on Solaris (Doc ID 1320890.1)” and possibly using matrace and libnjamd tools. We are not JAVA experts and need some guidance or exact commands to help guide the customer on how best to trace their code.
Customer would like to test this tracing as soon as Tuesday 12/22.
Any help would be appreciated!
Message was edited by: Danv-Oracle