[
https://issues.apache.org/jira/browse/ODE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697651#action_12697651
]
Ciaran Jessup commented on ODE-576:
-----------------------------------
Ok, with the patch I have no memory leaks, without the patch I lose memory,
badly ... when I traced the route you described (that was my starting place),
the 'conn' object in the deleteProcessDAO method that the cleanupProcess
delegates onto is an instance of org.apache.ode.dao.jpa.BpelDAOConnectionImpl,
this is *NOT* the same instance as the
org.apache.ode.bpel.memdao.BpelDAOConnectionImpl, where the processDAO instance
was *actually* originally stored. I appreciate that my patch may resolve the
issue in the correct way, but I am *certain* there is an issue here and I need
to resolve it in order to use ODE even lightly :(
I'm still also not convinced that the code in BpelProcess deleteProcessDao
definately is correct, if it is then its very strange, why on earth would you
choose *not* to delete a reference to an object which had a matching id in a
method called 'delete' (plus the logging comment is an inccorect cut'n'paste)
?? (sorry)
> ProcessDaoImpl objects get leaked when using in-memory-processes
> ----------------------------------------------------------------
>
> Key: ODE-576
> URL: https://issues.apache.org/jira/browse/ODE-576
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Environment: n/a
> Reporter: Ciaran Jessup
> Attachments: InMemoryProcessesLeakMemory.patch
>
>
> It seems that when I deploy and un-deploy in-memory processes ProcessDaoImpl
> objects stored in the __StateStore field of the BpelDAOConnectionFactoryImpl
> object are being left around.
> Over the course of several tens/hundreds of deployments the memory contained
> in these objects mounts up substantially :(
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
