I'm not sure whats changed recently on the ODE 1_xx branch  (i.e. in the
last 10 or so revisions)  but it seems as though the jpa store has started
to 'leak' references to its various 'DAOIMpl' objects, there was always a
leak of the VersionTrackerDAOImpl, but now the other ones have started
leaking... I'm not entirely worried about this as I believe they're only
weekly referenced, but they will eventually cause a full collect to occur
which I'd like to avoid if possible (I think).

Its driving me around the bend, but my in-experience of JPA and my confusion
of how an in-memory process relates to the JPA code is meaning I can't patch
it.   At one point I was reasonably convinced it was down to
org.apache.ode.store.jpa.DeploymentUnitDaoImpl.delete not correctly purging
all the child ProcessConfDaoImpl instances in its' _processes set (I'm not
convinced it isn't this but I've not been able to fix this by iterating and
removing, 'clear'ing the set, or pointing it at a new empty set) Help,
please! :)

This is the current set of 'leaks' for a single in-memory deployment (don't
worry about the scheduler, those 'new' instances cleanup) (the objects in
bold are the ones that worry me.

All Objects *Session:* Apache Tomcat 5.x on localhost *Time of
export:* Tuesday,
April 21, 2009 5:34:55 PM BST *JVM time:* 15:06    *Sorted by: * Instance
count *Aggregation level: * Packages
------------------------------

 NameInstance countDifferenceSize  org.apache.ode.bpel.iapi 190 (±0 %)728
bytes  org.apache.ode.scheduler.simple 180 (±0 %)808 bytes
 org.apache.ode.bpel.compiler.bom 180 (±0 %)648 bytes
 org.apache.ode.store.jpa 17+7 (+70 %)1,048 bytes     *org.**apache.**ode.**
store.**jpa.**VersionTrackerDAOImpl* 5+3 (+150 %)200 bytes *    org.**
apache.**ode.**store.**jpa.**ProcessConfDaoImpl* 5+2 (+67 %)400 bytes    *
 org.**apache.**ode.**store.**jpa.**DeploymentUnitDaoImpl* 5+2 (+67 %)360
bytes     org.apache.ode.store.jpa.ProcessConfPropertyDaoImpl 10 (±0 %)48
bytes     org.apache.ode.store.jpa.DbConfStoreConnectionFactory 10 (±0 %)40
bytes  org.apache.ode.bpel.engine 140 (±0 %)688 bytes
 org.apache.ode.bpel.pmapi 120 (±0 %)384 bytes  org.apache.ode.bpel.compiler
 100 (±0 %)640 bytes  org.apache.ode.axis2 90 (±0 %)448 bytes
 org.apache.ode.store 70 (±0 %)256 bytes  org.apache.ode.bpel.dao 60 (±0 %)144
bytes  org.apache.ode.axis2.service 60 (±0 %)240 bytes
 org.apache.ode.bpel.evt 60 (±0 %)224 bytes  org.apache.ode.axis2.hooks 50
(±0 %)200 bytes  org.apache.ode.bpel.epr 50 (±0 %)152 bytes
 org.apache.ode.il.config 50 (±0 %)192 bytes  org.apache.ode.axis2.deploy 40
(±0 %)264 bytes  org.apache.ode.dao.jpa 30 (±0 %)96 bytes
 org.apache.ode.bpel.dd 30 (±0 %)96 bytes  org.apache.ode.bpel.connector 20
(±0 %)72 bytes  org.apache.ode.utils.sax 2+1 (+100 %)48 bytes     *org.**
apache.**ode.**utils.**sax.**LoggingErrorHandler* 2+1 (+100 %)48 bytes
 org.apache.ode.utils.stl 20 (±0 %)32 bytes  org.apache.ode.il.dbutil 20 (±0
%)136 bytes  org.apache.ode.bpel.elang.xpath10.compiler 10 (±0 %)64 bytes
 org.apache.ode.utils.wsdl 10 (±0 %)64 bytes  org.apache.ode.utils 10 (±0 %)32
bytes  org.apache.ode.utils.xsd 10 (±0 %)64 bytes  org.apache.ode.utils.msg
 10 (±0 %)64 bytes  org.apache.ode.bpel.memdao 10 (±0 %)32 bytes
 org.apache.ode.jca.server.rmi 10 (±0 %)64 bytes
 org.apache.ode.bpel.bdi.breaks 10 (±0 %)24 bytes  org.apache.ode.utils.xsl
 10 (±0 %)32 bytes  org.apache.ode.bpel.compiler.wsdl 10 (±0 %)64 bytes
 org.apache.ode.bpel.extvar.jdbc 10 (±0 %)32 bytes *Total:**186**+8
(+4 %)**8,080
bytes*
My Frustration is that this was working ok last week as far as I can tell :(
 -cj.

Reply via email to