[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
8:46 a.m.
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
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
8:46 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Torsten Fink updated JBSEAM-3873:
---------------------------------
Attachment: MemoryLeakEventKontext.tgz
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
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
3:19 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-3873:
------------------------------
Fix Version/s: 2.1.2.CR1
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
Fix For: 2.1.2.CR1
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
5:07 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Assigned: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards reassigned JBSEAM-3873:
---------------------------------------
Assignee: Norman Richards
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.1.2.CR1
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
3:06 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards updated JBSEAM-3873:
------------------------------------
Fix Version/s: 2.1.2.GA
(was: 2.1.2.CR1)
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.1.2.GA
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
6:15 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards commented on JBSEAM-3873:
-----------------------------------------
I've spent some time looking at this and your analysis is correct.
EJBSynchronizations is in the event context. In the JMS context, the seam event context
only wraps the onMessage() invocation and sits INSIDE the the container management of the
request, including TX management. By the time the transaction is committed, the event
context has been destroyed and Seam has destroyed the EJBSynchronization object, making
the synchronization callbacks, which should do the jbpm context cleanup, fail.
There seem to be a couple of potential ways to solve this. If we can prevent Seam from
calling the remove method, everything works fine. (minus the session bean that
doesn't get removed). I'm not sure how to make that happen in a generic way
though...
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.1.2.CR2
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
5:59 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards updated JBSEAM-3873:
------------------------------------
Fix Version/s: 2.2.0
(was: 2.1.2.CR2)
Deferring this. It seems the solution for this will be too big to fit into this release.
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
1:54 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
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
11:11 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards commented on JBSEAM-3873:
-----------------------------------------
The problem with being in the event context is only that the remove method gets called.
When the container comes to fire the synchronization, it still knows about
EjbSynchronizations, but the bean has been removed and is skipped over. Not putting
EjbSynchronizations in any context works because the bean is still active when the tx
commits. However, then there is the problem of how to get that bean removed.
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
5:36 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Norman Richards updated JBSEAM-3873:
------------------------------------
Fix Version/s: The future
(was: 2.2.1.CR1)
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: The future
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
11:26 a.m.
New subject: [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Pete Muir updated JBSEAM-3873:
------------------------------
Assignee: (was: Norman Richards)
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
Fix For: The future
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
2:57 p.m.
New subject: [JBoss JIRA] Updated: (JBSEAM-3873) Memory leak using EJB transactions and jBpm contexts
[
https://jira.jboss.org/jira/browse/JBSEAM-3873?page=com.atlassian.jira.pl...
]
Tihomir Surdilovic updated JBSEAM-3873:
---------------------------------------
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
Fix For: The future
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
5441
days inactive
5855
days old
11 comments
4 participants
participants (4)
-
Norman Richards (JIRA) -
Pete Muir (JIRA)
-
Tihomir Surdilovic (JIRA)
-
Torsten Fink (JIRA)