[ http://jira.jboss.com/jira/browse/JBAS-1662?page=comments#action_12316777 ] Adrian Brock commented on JBAS-1662: ------------------------------------
SpecCompliant=true is a misnomer. It has nothing to do with spec compliance. In fact JBoss passed the j2ee1.4 compliance suite with this flag set to false. It is actually a backwards compatibility flag for an earlier implementation of the connection pooling in JBoss-3.0.0 I wouldn't recommend using it since you lose your connection close checking (which is probably the real cause of your memory leak). It is also not tested by the testsuite. Personally, I would like to implement the behaviour provided by this flag (lazy connection pooling - handle/managedconnection association). But it requires fixing the CCM to better link with the EJB lifecycle. See the attached issue. > 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
