You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ode.apache.org by Ciaran <ci...@gmail.com> on 2009/04/21 18:36:47 UTC
JPA Store seems to be 'leaky' for in-memory processes (all of a
sudden)
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.
Re: JPA Store seems to be 'leaky' for in-memory processes (all of a
sudden)
Posted by Ciaran <ci...@gmail.com>.
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 <ci...@gmail.com> 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 <ci...@gmail.com> 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.
>>
>>
>
Re: JPA Store seems to be 'leaky' for in-memory processes (all of a
sudden)
Posted by Ciaran <ci...@gmail.com>.
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 <ci...@gmail.com> 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.
>
>