Yi Wang created CMIS-868:
----------------------------

             Summary: OOM issue when run concurrent test on GetDescendant, 
GetTypeFlat, GetTypeTree.
                 Key: CMIS-868
                 URL: https://issues.apache.org/jira/browse/CMIS-868
             Project: Chemistry
          Issue Type: Bug
          Components: opencmis-client
    Affects Versions: OpenCMIS 0.12.0
         Environment: AIX 7.1+Websphere ND 8.5.5.3
Java(TM) SE Runtime Environment (build 
pap6460_26sr2ifix-20120419_02(SR2+IV19661))
IBM J9 VM (build 2.6, JRE 1.6.0 AIX ppc64-64 20120322_106210 (JIT enabled, AOT 
enabled)
J9VM - R26_Java626_SR2_20120322_1722_B106210
JIT  - r11_20120322_22976
GC   - R26_Java626_SR2_20120322_1722_B106210
J9CL - 20120322_106210)
JCL  - 20120316_01

            Reporter: Yi Wang
            Priority: Critical


When I run concurrent test with 100 threads on GetDescendants, GetTypeTree, 
GetTypeFlat function.

I found there are many hashtable objects(>500MB) saved in heap after analyzed 
heap dump. I found there was one line(red line below) in convertTypeDefinition 
method that chemistry used typeDefinition object as the key of HashMap. 
However, JAVA does not think 2 typeDefinition objects are same objects although 
the value of typeDefinition members are same. I debug to this line, the 
"result" variable always was "null". It made the objectTypecache larger and 
larger when run concurrent test.

 private ObjectType convertTypeDefinition(TypeDefinition typeDefinition) {
        lock.writeLock().lock();
        try {
            ObjectType result = null;
            if (objectTypeCache == null) {
                objectTypeCache = new IdentityHashMap<TypeDefinition, 
ObjectType>();
            } else {
                result = objectTypeCache.get(typeDefinition);
            }

            if (result == null) {
                result = objectFactory.convertTypeDefinition(typeDefinition);
                objectTypeCache.put(typeDefinition, result);
            }
            return result;
        } finally {
            lock.writeLock().unlock();
        }
    }




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to