[ http://jira.jboss.com/jira/browse/JBAS-1662?page=history ]
Adrian Brock updated JBAS-1662:
-------------------------------
Version: JBossAS-4.0.2RC1
JBossAS-4.0.1 SP1
JBossAS-4.0.1 Final
JBossAS-3.2.7 Final
Component: JCA service
(was: Transaction Manager service)
> Memory leak with SpecCompliant=true in transaction-service.xml
> --------------------------------------------------------------
>
> Key: JBAS-1662
> URL: http://jira.jboss.com/jira/browse/JBAS-1662
> Project: JBoss Application Server
> Type: Bug
> Components: JCA service
> Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,
> JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1
> Environment: jboss 3.2.6, linux 2.[46], DB2 7.[12]
> Reporter: Arto Huusko
>
>
> If SpecCompliant is set to true in transaction-service.xml, jboss begins to
> leak
> memory on a massive scale: all entity beans (both CMP and BMP) that become
> unused
> (that is: they are flushed from cache, and instance pool is full, so they are
> discarded) are never garbage collected.
> I don't pretend to understand the problem fully (I was in quite a rush to
> solve
> the memory leaks and it still took me over a week). I investigated the matter
> with a home-grown memory profiler, and found out that the leak ultimately
> occurs
> in org.jboss.resource.connectionmanager.CachedConnectionManager, which never
> releases the KeyConnectionAssociation objects (that are stored in a
> ThreadLocal
> LinkedList).
> And since KeyConnectionAssociation also holds a reference to the entity
> object,
> the entity objects leak once they are thrown out of the pool.
> And those KeyConnectionAssociation objects are of course created as a result
> of the entity beans opening connection to the database.
> I never found out why the KeyConnectionAssociation objects were never removed
> from the list (which would have resulted in garbage collection of the entity
> and all). I just saw somewhere in the code promising references to
> SpecCompliant, and thankfully it solved the problem for me.
> Note that leakage also occurs (immediately) if JBoss gets an entity from
> instance
> pool to run a finder, and the finder throws an exception. In that case, the
> entity used to run the finder is leaked immediately (the leakage happens in
> the
> same way as outlined above).
> I marked this problem for 3.2.6, but as far as I can see, the problem is the
> same in 3.2.7 and 4, too. Maybe priority should really be "minor", since I'm
> not sure that many people use SpecCompliant.
> Oh, and I also have Debug=true in transaction-service, if that makes any
> difference.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
