[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts

[Torsten Fink (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12464883#action_12464883 ] 

Torsten Fink commented on JBSEAM-3873:
--------------------------------------

When we reported the problem, we also thought about possible solutions. We did not come up with anything simple. Unfortunately this was 5 months ago and I do not remember the details anymore. What I remember is that the code was not easily understandable, thus, it was hard to estimate the consequences of changes. 

The root problem seems to be that the EJBSynchronization is an element of the event context, but has a different life cycle. It is created after the event context and should be deleted after the event context. This suggests to use some kind of association instead of an element-of relationship. 

The ThreadLocal approach could fit, because an event and a thread are quite similar, but there are many possibilities for doing it wrongly.

The context could be enhanced by some after destruction phase. In that phase associated components got cleaned up.

My gut feeling recommends the second approach. But, I probably would have to look at least two full days into the code to have a real opinion on this.

> Memory leak using EJB transactions and jBpm contexts
> ----------------------------------------------------
>
>                 Key: JBSEAM-3873
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3873
>             Project: Seam
>          Issue Type: Bug
>          Components: BPM, Core, EJB3
>    Affects Versions: 2.1.1.GA
>         Environment: JBoss 4.2.x, Mac OSX and Linux environments, Java 1.5
>            Reporter: Torsten Fink
>            Assignee: Norman Richards
>             Fix For: 2.2.0
>
>         Attachments: MemoryLeakEventKontext.tgz
>
>
> Our application had to survive a night with full load. On the next morning the heap was full of JbpmContext's. 
> After looking at the source code of Seam and at the debug messages we came up with this hypothesis: 
> * The SFSB EjbSynchronizations is placed in the event context, the Seam-JbpmContext-Component also lives in the event context. 
> * Using EJB transactions, EjbSynchronizations is responsible for cleaning up the JbpmContext after the end of the transaction. 
> * Unfortunately the event context ends BEFORE EjbSynchronizations has the chance to clean up the JbpmContext. 
> Using BMT the transaction ends before the event context ends. Thus, the JbpmContext is cleaned up. 
> We switch all our MDBs, EJB-timers, and Web-services from CMT to BMT and (after fixing some other leaks, e.g. a class loader issue in jBpm), we survived the night. 
> I wrote a small test application that shows the memory leak and I will try to attach it to this issue.
> It is a Maven application that consists of 
> - a Web-GUI to start the test and displays the results  (http://localhost:8080/leak/)
> - a SFSB that sends 10 messages each to two queues (the standard queues A and B), waits a little bit, and does a gc 
> - two MDBs, one with CMT, one with BMT, which uses Seam injection to access a jBpm-Context 
> - an application scoped POJO that saves the contexts in a Set using a weak reference 
> After executing the tests and the GC, the surviving references are displayed. You can see that the CMT references are not gs'ed whereas the BMT references are cleaned up. You can execute the test several times.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira