As yet another follow-up, the JPA objects are eventually being cleaned up (I could swear they went away then came back again at least once, but I've not been able to replicate that.) The LoggingErrorHandler growth is related to thread-usage, and is just a lazily initialized thread-local variable i.e. the more threads that get used the more of these that get instantiated (they're so lightweight a single instance could probably be reused I think, but its not a leak and it doesn't really matter :) )
P.s. *still* don't get why the JPA store seems so laissez-faire about its cleanup! - Cj. +1 for a 1.3.1 release when the vote begins! :) On Tue, Apr 21, 2009 at 5:46 PM, Ciaran <[email protected]> wrote: > Funny story :) After spending ages composing the previous mail, and going > to the effort of including tables etc. just after I sent it , I checked > back to the profiler and I can see that these 'excess' objects have now > 'removed' themselves from the heap, in which case I care even less about the > issue. *However* please could someone/anyone explain why they don't got > immediately after an un-deploy. Is this just the way that JPA works ? :) > - cj. > > P.s. the LoggingErrorHandler is definately leaking, to makeup for my > embarassing mis-post, I'll try and fix that instead... > > > > > On Tue, Apr 21, 2009 at 5:36 PM, Ciaran <[email protected]> wrote: > >> 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 19 0 (±0 %)728 >> bytes org.apache.ode.scheduler.simple 18 0 (±0 %)808 bytes >> org.apache.ode.bpel.compiler.bom 18 0 (±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 >> 1 0 (±0 %)48 bytes >> org.apache.ode.store.jpa.DbConfStoreConnectionFactory 1 0 (±0 %)40 bytes >> org.apache.ode.bpel.engine 14 0 (±0 %)688 bytes >> org.apache.ode.bpel.pmapi 12 0 (±0 %)384 bytes >> org.apache.ode.bpel.compiler 10 0 (±0 %)640 bytes org.apache.ode.axis2 >> 9 0 (±0 %)448 bytes org.apache.ode.store 7 0 (±0 %)256 bytes >> org.apache.ode.bpel.dao 6 0 (±0 %)144 bytes >> org.apache.ode.axis2.service 6 0 (±0 %)240 bytes >> org.apache.ode.bpel.evt 6 0 (±0 %)224 bytes org.apache.ode.axis2.hooks >> 5 0 (±0 %)200 bytes org.apache.ode.bpel.epr 5 0 (±0 %)152 bytes >> org.apache.ode.il.config 5 0 (±0 %)192 bytes >> org.apache.ode.axis2.deploy 4 0 (±0 %)264 bytes org.apache.ode.dao.jpa >> 3 0 (±0 %)96 bytes org.apache.ode.bpel.dd 3 0 (±0 %)96 bytes >> org.apache.ode.bpel.connector 2 0 (±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 2 0 (±0 %)32 bytes org.apache.ode.il.dbutil 2 0 >> (±0 %)136 bytes org.apache.ode.bpel.elang.xpath10.compiler 1 0 (±0 %)64 >> bytes org.apache.ode.utils.wsdl 1 0 (±0 %)64 bytes org.apache.ode.utils >> 1 0 (±0 %)32 bytes org.apache.ode.utils.xsd 1 0 (±0 %)64 bytes >> org.apache.ode.utils.msg 1 0 (±0 %)64 bytes org.apache.ode.bpel.memdao >> 1 0 (±0 %)32 bytes org.apache.ode.jca.server.rmi 1 0 (±0 %)64 bytes >> org.apache.ode.bpel.bdi.breaks 1 0 (±0 %)24 bytes >> org.apache.ode.utils.xsl 1 0 (±0 %)32 bytes >> org.apache.ode.bpel.compiler.wsdl 1 0 (±0 %)64 bytes >> org.apache.ode.bpel.extvar.jdbc 1 0 (±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. >> >> >
