[jira] [Commented] (CAY-1668) Memory Exhaustion Problem with Deserialization of ObjectContext

["Andrew Lindesay (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAY-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213512#comment-13213512 ] 

Andrew Lindesay commented on CAY-1668:
--------------------------------------

It does appear that the problem is in an Apache Commons abstract  superclass.  What is happening is that whilst running;

AbstractReferenceMap.doReadObject(..)

...the method...

AbstractReferenceMap.checkCapacity(..)

...is invoked and it seems to be doubling the size of the Map's entry array on de-serialization.  Through sequential serialization + de-serialization this yields the exponential growth in the memory consumption.

It seems that the problem is caused by the 'threshold' value being calculated after to populating the Map during de-serialization.

I have re-built 3.0-STABLE with commons 3.2.1 and it still seems to exhibit the same problem.

The release cycles for commons seems to be quite long these days.  Hmmm.....
                
> Memory Exhaustion Problem with Deserialization of ObjectContext
> ---------------------------------------------------------------
>
>                 Key: CAY-1668
>                 URL: https://issues.apache.org/jira/browse/CAY-1668
>             Project: Cayenne
>          Issue Type: Bug
>          Components: Core Library
>    Affects Versions: 3.0.2
>         Environment: MacOS-X 10.7, Java 1.6.0_29, Simple Web Application run in the Maven plugin "jetty-maven-plugin"
>            Reporter: Andrew Lindesay
>
> I am running a simple web application launched from maven using "jetty-maven-plugin".  The simple web application has a Filter which does this;
> 1) Copies the HttpSession's attributes to a Map
> 2) Serializes the Map
> 3) Deserializes the Map
> 4) Copies the entries of the Map back into HttpSession
> In each case, the ClassLoader should be the same (no stranded singletons etc...) and there is no "hot deploy" happening.  The purpose of this undertaking is to ensure that the application is able to handle serialized sessions.  In doing this experiment, I have observed a memory exhaustion issue around serializing and de-serializing ObjectContext.  If I explicitly stop serializing "ObjectContext" then the problem stops.
> Using jprofiler, I have observed that the memory consumption increases roughly exponentially in relation to the number of serialization/de-serialization events.  Also from jquery analysis I see the memory is being referenced from;
>     org.apache.commons.collections.map.AbstractHashedMap$HashEntry[]
>     > org.apache.commons.collecitons.map.LRUMap
>     >> org.apache.cayenne.access.jdbc.SQLTemplateResourceManager
>     >>> ...velocity
> The problem manifests itself quite quickly; a few dozen serialize + de-serialize phases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira