You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Rick Roman <ri...@cotse.net> on 2006/01/23 18:56:37 UTC
Re: Tomcat 5, JNDI, Perm Gen Memory leak
I upgraded to the new db-ojb-1.0.4 which has the method
PersistenceBrokerFactoryFactory.instance().shutdown();
This results in exception:
[ERROR] mffweb] - Exception sending context destroyed event to listener
instance of class org.mff.web.listener.CleanupListener
<java.lang.NoSuchMethodError:
org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
at
org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
Still have memory leak or (I suppose more accurtately, failure to clean
up resources). Anyone have any ideas or has anyone ever actually been
able to avoid this problem or am I just stuck with it?
Armin Waibel wrote:
> Hi Rick,
>
> Rick Roman wrote:
>
>> Sorry to be dense but can you send me the link to cvs for revision
>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>
>
> Think this will not work, because the changes will affect other
> classes too.
> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>
> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
> test-suite show some odmg-api specific test failures, will be fixed
> soon).
>
> regards,
> Armin
>
>
>> Ilkka Priha wrote:
>>
>>> Rick,
>>>
>>> It was introduced in revision 1.4.2.2 of PersistenceBrokerFactoryIF
>>> (25/07/05), so it's available only in the cvs version of OJB, but
>>> hopefully quite soon also as 1.0.4-rc.
>>>
>>> -- Ilkka
>>>
>>> /**
>>> * Shutdown method for OJB, kills all running processes within OJB -
>>> after
>>> * shutdown OJB can no longer be used.
>>> * <br/>
>>> * This method is introduced to solve hot/redeployment problems
>>> (memory leaks) caused by
>>> * the usage of {@link ThreadLocal} instances in OJB source and the
>>> reuse of threads
>>> * by the container (e.g. servlet- or ejb-container).
>>> */
>>> public void shutdown();
>>>
>>>
>>> Rick Roman wrote:
>>>
>>>> Hi Ilkka,
>>>>
>>>> shutdown() does not appear to be a method of
>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>> this available?
>>>>
>>>> Ilkka Priha wrote:
>>>>
>>>>> Hi Rick,
>>>>>
>>>>> Have you tried this one, it alone should do the job.
>>>>>
>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>
>>>>> -- Ilkka
>>>>>
>>>>>
>>>>> Rick Roman wrote:
>>>>>
>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>> listener to run:
>>>>>>
>>>>>> PersistenceBroker broker =
>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>> broker.clearCache();
>>>>>> broker.close();
>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>
>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>
>>>>>> and the leak still persists.
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>> problem is that every time I reload my application context, I
>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>> reloads, tomcat eventually crashes with an out of memory error.
>>>>>>> I believe this has to do with my OBJ configuration as I am able
>>>>>>> to access the datasource without OBJ and I don't see the
>>>>>>> problem. The memory leak problem is a known issue, discussed in
>>>>>>> detail here:
>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>> tomcat) still has a reference to the application class loader or
>>>>>>> any object loaded by it, the class loader will not be garbage
>>>>>>> collected. In that case, all the class objects and every object
>>>>>>> referenced by a static field in any of the classes will not be
>>>>>>> garbage collected."
>>>>>>>
>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>
>>>>>>> repository.xml
>>>>>>> <jdbc-connection-descriptor
>>>>>>> jcd-alias="default"
>>>>>>> default-connection="true"
>>>>>>> platform="PostgreSQL"
>>>>>>> jdbc-level="3.0"
>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>> eager-release="false"
>>>>>>> batch-mode="false"
>>>>>>> useAutoCommit="1"
>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>> attribute-value=""/>
>>>>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>>>>> <attribute attribute-name="autoSync"
>>>>>>> attribute-value="true"/>
>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>> attribute-value="0"/>
>>>>>>> </object-cache>
>>>>>>> <sequence-manager
>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>
>>>>>>> </sequence-manager>
>>>>>>> </jdbc-connection-descriptor >
>>>>>>>
>>>>>>> OBJ.properties
>>>>>>> repositoryFile=repository.xml
>>>>>>> useSerializedRepository=false
>>>>>>> serializedRepositoryPath=.
>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>
>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>
>>>>>>> maxActive=256
>>>>>>> maxIdle=-1
>>>>>>> maxWait=2000
>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>> whenExhaustedAction=0
>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>
>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>
>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>
>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>
>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>
>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>
>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>
>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>
>>>>>>> descriptorBasedCaches=false
>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>
>>>>>>> LockTimeout=60000
>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>
>>>>>>> SqlInLimit=200
>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>> cascadingDeleteOneToOne=false
>>>>>>> cascadingDeleteOneToN=false
>>>>>>> cascadingDeleteMToN=false
>>>>>>> ImplicitLocking=true
>>>>>>> LockAssociations=WRITE
>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>
>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Thomas Dudziak <to...@gmail.com>.
Hi folks,
after some serious profiling (and finding a bug in the Mustang b68
VM), I've added some additional cleanup calls to OJB (SVN of the
stable branch). Please give it a try to see whether that suffices.
However, you also need to do some work in your own webapp to ensure
proper cleanup. The standard way is to use a servlet context listener
like this (based upon Rick's test webapp):
public class CleanupListener implements ServletContextListener
{
public void contextInitialized(ServletContextEvent event)
{ }
public void contextDestroyed(ServletContextEvent event)
{
PersistenceBrokerFactory.shutdown();
LogFactory.releaseAll();
for (Enumeration e = DriverManager.getDrivers(); e.hasMoreElements();)
{
Driver driver = (Driver)e.nextElement();
if (driver.getClass().getClassLoader() == getClass().getClassLoader())
{
try
{
DriverManager.deregisterDriver(driver);
}
catch (SQLException ex)
{
ex.printStackTrace();
}
}
}
}
}
What this does is basically performing OJB cleanup, commons-logging
cleanup, and cleanup of all JDBC drivers loaded in the webapp (which
is for instance necessary for the MySql driver).
For more info see also here:
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Thomas Dudziak <to...@gmail.com>.
On 1/24/06, Rick Roman <ri...@cotse.net> wrote:
> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
> stripped down context with the minimum classes needed to run OJB and
> could pin the memory increase to touching anything that initiallized
> OJB. I have also chased down other known offenders such as deregistering
> the database driver and logging.
Could you provide me a simple example web app ? I would profile/debug
it then to see what's wrong.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Armin Waibel <ar...@apache.org>.
Hi Danilo,
Danilo Tommasina wrote:
> Hi, sorry for the long delay.
>
> I just upgarded to 1.0.4 (official release not SVN) from 1.0.3 and
> removed my previous workarounds in our code for avoiding the leak.
> The new version works for me without PermGen leaks. (Just as reminder,
> we just use the PB API and not even in its full extension)
> Now just calling the PersistenceBrokerFactory.shutdown() seem to clean
> up stuff as expected.
>
Good news! Thanks for clarify this.
regards,
Armin
> Just as a side notice about my previous e-mail, the amd64 JVM version
> has only the 'server' VM and this one leaks, nothing to do with OJB.
>
> bye
> danilo
>
> Rick Roman wrote:
>> I am using Java 1.5.0_01 and Tomcat 5.5.4 on my home machine and
>> 1.5.0_05 / 5.5.9 on my remote developement server. I use jconsole on
>> the home machine to watch the leak. The remote has the problem too as
>> evidenced that it runs out of memory after about 15 reloads.
>>
>> Danilo Tommasina wrote:
>>
>>> mmmh, yep I forget to say the following:
>>>
>>> we use the client VM and not the server VM.
>>>
>>> I am using JDK 1.5.0_04 on a gentoo linux, we also have deployments
>>> on Windows XP, Mac OSX, Solaris and Debian linux, with different JDK
>>> Versions also of JDK 1.4.2, however all quite up-to-date. No PermGen
>>> leaks!
>>>
>>> But... I tested it at home on my AMD64 gentoo distribution with 64
>>> bit VM (JDK 1.5.0_06), and guess what, memory leak was there... I did
>>> no investigate it deeply yet, I'll have to try to update to JDK
>>> 1.5.0_06 and test it on a 32 bit VM, maybe there is a difference
>>> there...
>>>
>>> on my machine I start tomcat with following JAVA_OPTS, however other
>>> machines are started with default options with just the -Xmx set to a
>>> higher value:
>>> JAVA_OPTS="$JAVA_OPTS -Xmx512m -XX:+UseParNewGC
>>> -XX:+UseConcMarkSweepGC -XX:+TraceClassUnloading -XX:+ClassUnloading
>>> -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
>>> -Dcom.sun.management.jmxremote=true"
>>>
>>> This will print out when classes are unloaded and allow you to
>>> connect with JConsole (needs JDK 1.5)
>>>
>>> what JDK / JVM are you using?
>>> maybe if I get some time I'll try out the BEA JRockit VM as reported
>>> by Craig A. Vanderborgh.
>>>
>>> bye
>>> danilo
>>>
>>> Rick Roman wrote:
>>>
>>>> I am only using the PB API too.
>>>>
>>>> Danilo Tommasina wrote:
>>>>
>>>>> hi again,
>>>>>
>>>>> this is quite an old version of tomcat, we were not having trouble
>>>>> for sure since tomcat 5.5.9, no idea how it was with earlier versions.
>>>>> anyways, if this is not the problem, it could be still OJB that
>>>>> causes the leak. My patch fixed one situation but there may be
>>>>> other parts having the same/similar problem. We are using only the
>>>>> PB API.
>>>>> If I remeber well there are also other parts of OJB that make use
>>>>> of the 'dangerous' ThreadLocal class, I think it was something with
>>>>> per thread metadata repository, maybe there are other problems too
>>>>> in ODMG... I do not know, sorry.
>>>>>
>>>>>
>>>>>> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created
>>>>>> a stripped down context with the minimum classes needed to run OJB
>>>>>> and could pin the memory increase to touching anything that
>>>>>> initiallized OJB. I have also chased down other known offenders
>>>>>> such as deregistering the database driver and logging.
>>>>>>
>>>>>> Danilo Tommasina wrote:
>>>>>>
>>>>>>> Sorry I still did not update to 1.0.4 and was not able to test it
>>>>>>> out against the memory leak.
>>>>>>> We are using a patched version of OJB, patched by myself, but as
>>>>>>> long as I remember it is almost the same code as in the 1.0.4
>>>>>>> version.
>>>>>>>
>>>>>>> what app- web-server are you using? version? note that in tomcat
>>>>>>> versions < 4.1.31 and probably some earlier 5.5.x verions there
>>>>>>> were bugs that prevented a clean shutdown of a web-application.
>>>>>>>
>>>>>>> Do you have any threads or other stuff that is still running?
>>>>>>> External libraries?
>>>>>>> We had the same problem caused by the quartz scheduler for example.
>>>>>>>
>>>>>>> As soon as I can, I'll try to update to 1.0.4 and test out the
>>>>>>> memory leak problem.
>>>>>>>
>>>>>>> cheers
>>>>>>> Danilo
>>>>>>
>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Danilo Tommasina <dt...@risksys.com>.
Hi, sorry for the long delay.
I just upgarded to 1.0.4 (official release not SVN) from 1.0.3 and removed my previous workarounds in our code for avoiding the leak.
The new version works for me without PermGen leaks. (Just as reminder, we just use the PB API and not even in its full extension)
Now just calling the PersistenceBrokerFactory.shutdown() seem to clean up stuff as expected.
Just as a side notice about my previous e-mail, the amd64 JVM version has only the 'server' VM and this one leaks, nothing to do with OJB.
bye
danilo
Rick Roman wrote:
> I am using Java 1.5.0_01 and Tomcat 5.5.4 on my home machine and
> 1.5.0_05 / 5.5.9 on my remote developement server. I use jconsole on the
> home machine to watch the leak. The remote has the problem too as
> evidenced that it runs out of memory after about 15 reloads.
>
> Danilo Tommasina wrote:
>
>> mmmh, yep I forget to say the following:
>>
>> we use the client VM and not the server VM.
>>
>> I am using JDK 1.5.0_04 on a gentoo linux, we also have deployments on
>> Windows XP, Mac OSX, Solaris and Debian linux, with different JDK
>> Versions also of JDK 1.4.2, however all quite up-to-date. No PermGen
>> leaks!
>>
>> But... I tested it at home on my AMD64 gentoo distribution with 64 bit
>> VM (JDK 1.5.0_06), and guess what, memory leak was there... I did no
>> investigate it deeply yet, I'll have to try to update to JDK 1.5.0_06
>> and test it on a 32 bit VM, maybe there is a difference there...
>>
>> on my machine I start tomcat with following JAVA_OPTS, however other
>> machines are started with default options with just the -Xmx set to a
>> higher value:
>> JAVA_OPTS="$JAVA_OPTS -Xmx512m -XX:+UseParNewGC
>> -XX:+UseConcMarkSweepGC -XX:+TraceClassUnloading -XX:+ClassUnloading
>> -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
>> -Dcom.sun.management.jmxremote=true"
>>
>> This will print out when classes are unloaded and allow you to connect
>> with JConsole (needs JDK 1.5)
>>
>> what JDK / JVM are you using?
>> maybe if I get some time I'll try out the BEA JRockit VM as reported
>> by Craig A. Vanderborgh.
>>
>> bye
>> danilo
>>
>> Rick Roman wrote:
>>
>>> I am only using the PB API too.
>>>
>>> Danilo Tommasina wrote:
>>>
>>>> hi again,
>>>>
>>>> this is quite an old version of tomcat, we were not having trouble
>>>> for sure since tomcat 5.5.9, no idea how it was with earlier versions.
>>>> anyways, if this is not the problem, it could be still OJB that
>>>> causes the leak. My patch fixed one situation but there may be other
>>>> parts having the same/similar problem. We are using only the PB API.
>>>> If I remeber well there are also other parts of OJB that make use of
>>>> the 'dangerous' ThreadLocal class, I think it was something with per
>>>> thread metadata repository, maybe there are other problems too in
>>>> ODMG... I do not know, sorry.
>>>>
>>>>
>>>>> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
>>>>> stripped down context with the minimum classes needed to run OJB
>>>>> and could pin the memory increase to touching anything that
>>>>> initiallized OJB. I have also chased down other known offenders
>>>>> such as deregistering the database driver and logging.
>>>>>
>>>>> Danilo Tommasina wrote:
>>>>>
>>>>>> Sorry I still did not update to 1.0.4 and was not able to test it
>>>>>> out against the memory leak.
>>>>>> We are using a patched version of OJB, patched by myself, but as
>>>>>> long as I remember it is almost the same code as in the 1.0.4
>>>>>> version.
>>>>>>
>>>>>> what app- web-server are you using? version? note that in tomcat
>>>>>> versions < 4.1.31 and probably some earlier 5.5.x verions there
>>>>>> were bugs that prevented a clean shutdown of a web-application.
>>>>>>
>>>>>> Do you have any threads or other stuff that is still running?
>>>>>> External libraries?
>>>>>> We had the same problem caused by the quartz scheduler for example.
>>>>>>
>>>>>> As soon as I can, I'll try to update to 1.0.4 and test out the
>>>>>> memory leak problem.
>>>>>>
>>>>>> cheers
>>>>>> Danilo
>>>>>
>>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
--
Danilo Tommasina, Dipl. Ing. FH Telecom
Software Engineer, Chief Technology Officer
RCS Riskmanagement Concepts Systems AG
Technoparkstrasse 1
CH-8005 Zuerich
T: +41 1 445 29 08
dtommasina@risksys.com
www.risksys.com
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
I am using Java 1.5.0_01 and Tomcat 5.5.4 on my home machine and
1.5.0_05 / 5.5.9 on my remote developement server. I use jconsole on the
home machine to watch the leak. The remote has the problem too as
evidenced that it runs out of memory after about 15 reloads.
Danilo Tommasina wrote:
> mmmh, yep I forget to say the following:
>
> we use the client VM and not the server VM.
>
> I am using JDK 1.5.0_04 on a gentoo linux, we also have deployments on
> Windows XP, Mac OSX, Solaris and Debian linux, with different JDK
> Versions also of JDK 1.4.2, however all quite up-to-date. No PermGen
> leaks!
>
> But... I tested it at home on my AMD64 gentoo distribution with 64 bit
> VM (JDK 1.5.0_06), and guess what, memory leak was there... I did no
> investigate it deeply yet, I'll have to try to update to JDK 1.5.0_06
> and test it on a 32 bit VM, maybe there is a difference there...
>
> on my machine I start tomcat with following JAVA_OPTS, however other
> machines are started with default options with just the -Xmx set to a
> higher value:
> JAVA_OPTS="$JAVA_OPTS -Xmx512m -XX:+UseParNewGC
> -XX:+UseConcMarkSweepGC -XX:+TraceClassUnloading -XX:+ClassUnloading
> -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
> -Dcom.sun.management.jmxremote=true"
>
> This will print out when classes are unloaded and allow you to connect
> with JConsole (needs JDK 1.5)
>
> what JDK / JVM are you using?
> maybe if I get some time I'll try out the BEA JRockit VM as reported
> by Craig A. Vanderborgh.
>
> bye
> danilo
>
> Rick Roman wrote:
>
>> I am only using the PB API too.
>>
>> Danilo Tommasina wrote:
>>
>>> hi again,
>>>
>>> this is quite an old version of tomcat, we were not having trouble
>>> for sure since tomcat 5.5.9, no idea how it was with earlier versions.
>>> anyways, if this is not the problem, it could be still OJB that
>>> causes the leak. My patch fixed one situation but there may be other
>>> parts having the same/similar problem. We are using only the PB API.
>>> If I remeber well there are also other parts of OJB that make use of
>>> the 'dangerous' ThreadLocal class, I think it was something with per
>>> thread metadata repository, maybe there are other problems too in
>>> ODMG... I do not know, sorry.
>>>
>>>
>>>> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
>>>> stripped down context with the minimum classes needed to run OJB
>>>> and could pin the memory increase to touching anything that
>>>> initiallized OJB. I have also chased down other known offenders
>>>> such as deregistering the database driver and logging.
>>>>
>>>> Danilo Tommasina wrote:
>>>>
>>>>> Sorry I still did not update to 1.0.4 and was not able to test it
>>>>> out against the memory leak.
>>>>> We are using a patched version of OJB, patched by myself, but as
>>>>> long as I remember it is almost the same code as in the 1.0.4
>>>>> version.
>>>>>
>>>>> what app- web-server are you using? version? note that in tomcat
>>>>> versions < 4.1.31 and probably some earlier 5.5.x verions there
>>>>> were bugs that prevented a clean shutdown of a web-application.
>>>>>
>>>>> Do you have any threads or other stuff that is still running?
>>>>> External libraries?
>>>>> We had the same problem caused by the quartz scheduler for example.
>>>>>
>>>>> As soon as I can, I'll try to update to 1.0.4 and test out the
>>>>> memory leak problem.
>>>>>
>>>>> cheers
>>>>> Danilo
>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Danilo Tommasina <dt...@risksys.com>.
mmmh, yep I forget to say the following:
we use the client VM and not the server VM.
I am using JDK 1.5.0_04 on a gentoo linux, we also have deployments on Windows XP, Mac OSX, Solaris and Debian linux, with different JDK Versions also of JDK
1.4.2, however all quite up-to-date. No PermGen leaks!
But... I tested it at home on my AMD64 gentoo distribution with 64 bit VM (JDK 1.5.0_06), and guess what, memory leak was there... I did no investigate it
deeply yet, I'll have to try to update to JDK 1.5.0_06 and test it on a 32 bit VM, maybe there is a difference there...
on my machine I start tomcat with following JAVA_OPTS, however other machines are started with default options with just the -Xmx set to a higher value:
JAVA_OPTS="$JAVA_OPTS -Xmx512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+TraceClassUnloading -XX:+ClassUnloading -XX:+CMSPermGenSweepingEnabled
-XX:+CMSClassUnloadingEnabled -Dcom.sun.management.jmxremote=true"
This will print out when classes are unloaded and allow you to connect with JConsole (needs JDK 1.5)
what JDK / JVM are you using?
maybe if I get some time I'll try out the BEA JRockit VM as reported by Craig A. Vanderborgh.
bye
danilo
Rick Roman wrote:
> I am only using the PB API too.
>
> Danilo Tommasina wrote:
>
>> hi again,
>>
>> this is quite an old version of tomcat, we were not having trouble for
>> sure since tomcat 5.5.9, no idea how it was with earlier versions.
>> anyways, if this is not the problem, it could be still OJB that causes
>> the leak. My patch fixed one situation but there may be other parts
>> having the same/similar problem. We are using only the PB API.
>> If I remeber well there are also other parts of OJB that make use of
>> the 'dangerous' ThreadLocal class, I think it was something with per
>> thread metadata repository, maybe there are other problems too in
>> ODMG... I do not know, sorry.
>>
>>
>>> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
>>> stripped down context with the minimum classes needed to run OJB and
>>> could pin the memory increase to touching anything that initiallized
>>> OJB. I have also chased down other known offenders such as
>>> deregistering the database driver and logging.
>>>
>>> Danilo Tommasina wrote:
>>>
>>>> Sorry I still did not update to 1.0.4 and was not able to test it
>>>> out against the memory leak.
>>>> We are using a patched version of OJB, patched by myself, but as
>>>> long as I remember it is almost the same code as in the 1.0.4 version.
>>>>
>>>> what app- web-server are you using? version? note that in tomcat
>>>> versions < 4.1.31 and probably some earlier 5.5.x verions there were
>>>> bugs that prevented a clean shutdown of a web-application.
>>>>
>>>> Do you have any threads or other stuff that is still running?
>>>> External libraries?
>>>> We had the same problem caused by the quartz scheduler for example.
>>>>
>>>> As soon as I can, I'll try to update to 1.0.4 and test out the
>>>> memory leak problem.
>>>>
>>>> cheers
>>>> Danilo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
I am only using the PB API too.
Danilo Tommasina wrote:
> hi again,
>
> this is quite an old version of tomcat, we were not having trouble for
> sure since tomcat 5.5.9, no idea how it was with earlier versions.
> anyways, if this is not the problem, it could be still OJB that causes
> the leak. My patch fixed one situation but there may be other parts
> having the same/similar problem. We are using only the PB API.
> If I remeber well there are also other parts of OJB that make use of
> the 'dangerous' ThreadLocal class, I think it was something with per
> thread metadata repository, maybe there are other problems too in
> ODMG... I do not know, sorry.
>
>
>> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
>> stripped down context with the minimum classes needed to run OJB and
>> could pin the memory increase to touching anything that initiallized
>> OJB. I have also chased down other known offenders such as
>> deregistering the database driver and logging.
>>
>> Danilo Tommasina wrote:
>>
>>> Sorry I still did not update to 1.0.4 and was not able to test it
>>> out against the memory leak.
>>> We are using a patched version of OJB, patched by myself, but as
>>> long as I remember it is almost the same code as in the 1.0.4 version.
>>>
>>> what app- web-server are you using? version? note that in tomcat
>>> versions < 4.1.31 and probably some earlier 5.5.x verions there were
>>> bugs that prevented a clean shutdown of a web-application.
>>>
>>> Do you have any threads or other stuff that is still running?
>>> External libraries?
>>> We had the same problem caused by the quartz scheduler for example.
>>>
>>> As soon as I can, I'll try to update to 1.0.4 and test out the
>>> memory leak problem.
>>>
>>> cheers
>>> Danilo
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Danilo Tommasina <dt...@risksys.com>.
hi again,
this is quite an old version of tomcat, we were not having trouble for sure since tomcat 5.5.9, no idea how it was with earlier versions.
anyways, if this is not the problem, it could be still OJB that causes the leak. My patch fixed one situation but there may be other parts having the
same/similar problem. We are using only the PB API.
If I remeber well there are also other parts of OJB that make use of the 'dangerous' ThreadLocal class, I think it was something with per thread metadata
repository, maybe there are other problems too in ODMG... I do not know, sorry.
> I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
> stripped down context with the minimum classes needed to run OJB and
> could pin the memory increase to touching anything that initiallized
> OJB. I have also chased down other known offenders such as deregistering
> the database driver and logging.
>
> Danilo Tommasina wrote:
>
>> Sorry I still did not update to 1.0.4 and was not able to test it out
>> against the memory leak.
>> We are using a patched version of OJB, patched by myself, but as long
>> as I remember it is almost the same code as in the 1.0.4 version.
>>
>> what app- web-server are you using? version? note that in tomcat
>> versions < 4.1.31 and probably some earlier 5.5.x verions there were
>> bugs that prevented a clean shutdown of a web-application.
>>
>> Do you have any threads or other stuff that is still running? External
>> libraries?
>> We had the same problem caused by the quartz scheduler for example.
>>
>> As soon as I can, I'll try to update to 1.0.4 and test out the memory
>> leak problem.
>>
>> cheers
>> Danilo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
I am using Tomcat 5.5.4. I am almost certain it is OJB. I created a
stripped down context with the minimum classes needed to run OJB and
could pin the memory increase to touching anything that initiallized
OJB. I have also chased down other known offenders such as deregistering
the database driver and logging.
Danilo Tommasina wrote:
> Sorry I still did not update to 1.0.4 and was not able to test it out
> against the memory leak.
> We are using a patched version of OJB, patched by myself, but as long
> as I remember it is almost the same code as in the 1.0.4 version.
>
> what app- web-server are you using? version? note that in tomcat
> versions < 4.1.31 and probably some earlier 5.5.x verions there were
> bugs that prevented a clean shutdown of a web-application.
>
> Do you have any threads or other stuff that is still running? External
> libraries?
> We had the same problem caused by the quartz scheduler for example.
>
> As soon as I can, I'll try to update to 1.0.4 and test out the memory
> leak problem.
>
> cheers
> Danilo
>
> Rick Roman wrote:
>
>> OK I'm really on version 1.0.4 now and all of these methods run
>> without error. Unfortunately, none of them have any effect on the
>> memory leak.
>>
>> PersistenceBroker broker =
>> PersistenceBrokerFactory.defaultPersistenceBroker();
>> broker.clearCache();
>> broker.close();
>> PersistenceBrokerFactory.releaseAllInstances();
>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>
>> PersistenceBrokerThreadMapping.shutdown();
>> PersistenceBrokerFactoryFactory.instance().shutdown();
>> PersistenceBrokerFactory.shutdown();
>>
>> Rick Roman wrote:
>>
>>> You were correct. I had a ghost version of 1.0.3 in my path. Thanks.
>>>
>>> Antonio Gallardo wrote:
>>>
>>>> hi,
>>>>
>>>> Seems like an class loader issue. Can you check if there are not
>>>> older ojb.jar in your classpath loaded before the ojb 1.0.4?
>>>>
>>>> Best Regards,
>>>>
>>>> Antonio Gallardo.
>>>>
>>>> Rick Roman wrote:
>>>>
>>>>> I upgraded to the new db-ojb-1.0.4 which has the method
>>>>>
>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>
>>>>> This results in exception:
>>>>>
>>>>> [ERROR] mffweb] - Exception sending context destroyed event to
>>>>> listener instance of class org.mff.web.listener.CleanupListener
>>>>> <java.lang.NoSuchMethodError:
>>>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>>>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>>>>> at
>>>>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>>>>
>>>>>
>>>>> Still have memory leak or (I suppose more accurtately, failure to
>>>>> clean up resources). Anyone have any ideas or has anyone ever
>>>>> actually been able to avoid this problem or am I just stuck with it?
>>>>>
>>>>>
>>>>> Armin Waibel wrote:
>>>>>
>>>>>> Hi Rick,
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> Sorry to be dense but can you send me the link to cvs for
>>>>>>> revision 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having
>>>>>>> trouble locating it.
>>>>>>>
>>>>>>
>>>>>> Think this will not work, because the changes will affect other
>>>>>> classes too.
>>>>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>>>>
>>>>>> I recommend to use the latest from OJB 1.0.x branch
>>>>>> (OJB_1_0_RELEASE branch, trunk is unstable 1.x). The 1.0.x branch
>>>>>> is 95% stable (the test-suite show some odmg-api specific test
>>>>>> failures, will be fixed soon).
>>>>>>
>>>>>> regards,
>>>>>> Armin
>>>>>>
>>>>>>
>>>>>>> Ilkka Priha wrote:
>>>>>>>
>>>>>>>> Rick,
>>>>>>>>
>>>>>>>> It was introduced in revision 1.4.2.2 of
>>>>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only
>>>>>>>> in the cvs version of OJB, but hopefully quite soon also as
>>>>>>>> 1.0.4-rc.
>>>>>>>>
>>>>>>>> -- Ilkka
>>>>>>>>
>>>>>>>> /**
>>>>>>>> * Shutdown method for OJB, kills all running processes within
>>>>>>>> OJB - after
>>>>>>>> * shutdown OJB can no longer be used.
>>>>>>>> * <br/>
>>>>>>>> * This method is introduced to solve hot/redeployment problems
>>>>>>>> (memory leaks) caused by
>>>>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>>>>> the reuse of threads
>>>>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>>>>> */
>>>>>>>> public void shutdown();
>>>>>>>>
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> Hi Ilkka,
>>>>>>>>>
>>>>>>>>> shutdown() does not appear to be a method of
>>>>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch
>>>>>>>>> with this available?
>>>>>>>>>
>>>>>>>>> Ilkka Priha wrote:
>>>>>>>>>
>>>>>>>>>> Hi Rick,
>>>>>>>>>>
>>>>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>>>>
>>>>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>>>>
>>>>>>>>>> -- Ilkka
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Rick Roman wrote:
>>>>>>>>>>
>>>>>>>>>>> Update: From other threads, I have tried using a
>>>>>>>>>>> contextDestroy listener to run:
>>>>>>>>>>>
>>>>>>>>>>> PersistenceBroker broker =
>>>>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>>>>> broker.clearCache();
>>>>>>>>>>> broker.close();
>>>>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>>>>
>>>>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>>>>
>>>>>>>>>>> and the leak still persists.
>>>>>>>>>>>
>>>>>>>>>>> Rick Roman wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource.
>>>>>>>>>>>> My problem is that every time I reload my application
>>>>>>>>>>>> context, I get a big jump in Tomcat Perm Gen memory. After
>>>>>>>>>>>> a several reloads, tomcat eventually crashes with an out of
>>>>>>>>>>>> memory error. I believe this has to do with my OBJ
>>>>>>>>>>>> configuration as I am able to access the datasource without
>>>>>>>>>>>> OBJ and I don't see the problem. The memory leak problem is
>>>>>>>>>>>> a known issue, discussed in detail here:
>>>>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>>>>> In short, the problem is that "if any object that is loaded
>>>>>>>>>>>> by the system or container classloader (StandardClassLoader
>>>>>>>>>>>> in tomcat) still has a reference to the application class
>>>>>>>>>>>> loader or any object loaded by it, the class loader will
>>>>>>>>>>>> not be garbage collected. In that case, all the class
>>>>>>>>>>>> objects and every object referenced by a static field in
>>>>>>>>>>>> any of the classes will not be garbage collected."
>>>>>>>>>>>>
>>>>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>>>>
>>>>>>>>>>>> repository.xml
>>>>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>>>>> jcd-alias="default"
>>>>>>>>>>>> default-connection="true"
>>>>>>>>>>>> platform="PostgreSQL"
>>>>>>>>>>>> jdbc-level="3.0"
>>>>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>>>>> eager-release="false"
>>>>>>>>>>>> batch-mode="false"
>>>>>>>>>>>> useAutoCommit="1"
>>>>>>>>>>>> ignoreAutoCommitExceptions="false" >
>>>>>>>>>>>> <object-cache
>>>>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>>>>> attribute-value=""/>
>>>>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>>>>> attribute-value="900"/>
>>>>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>>>>> attribute-value="true"/>
>>>>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>>>>> attribute-value="0"/>
>>>>>>>>>>>> </object-cache>
>>>>>>>>>>>> <sequence-manager
>>>>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>>>>
>>>>>>>>>>>> </sequence-manager>
>>>>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>>>>
>>>>>>>>>>>> OBJ.properties
>>>>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>>>>> useSerializedRepository=false
>>>>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>>>>
>>>>>>>>>>>> maxActive=256
>>>>>>>>>>>> maxIdle=-1
>>>>>>>>>>>> maxWait=2000
>>>>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>>>>> whenExhaustedAction=0
>>>>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>>>>
>>>>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>>>>
>>>>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>>>>
>>>>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>>>>>
>>>>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>>>>
>>>>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>>>>
>>>>>>>>>>>> LockTimeout=60000
>>>>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>>>>
>>>>>>>>>>>> SqlInLimit=200
>>>>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>>>>> ImplicitLocking=true
>>>>>>>>>>>> LockAssociations=WRITE
>>>>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>>>>
>>>>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>>>>
>>>>>>>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Danilo Tommasina <dt...@risksys.com>.
Sorry I still did not update to 1.0.4 and was not able to test it out against the memory leak.
We are using a patched version of OJB, patched by myself, but as long as I remember it is almost the same code as in the 1.0.4 version.
what app- web-server are you using? version? note that in tomcat versions < 4.1.31 and probably some earlier 5.5.x verions there were bugs that prevented a
clean shutdown of a web-application.
Do you have any threads or other stuff that is still running? External libraries?
We had the same problem caused by the quartz scheduler for example.
As soon as I can, I'll try to update to 1.0.4 and test out the memory leak problem.
cheers
Danilo
Rick Roman wrote:
> OK I'm really on version 1.0.4 now and all of these methods run without
> error. Unfortunately, none of them have any effect on the memory leak.
>
> PersistenceBroker broker =
> PersistenceBrokerFactory.defaultPersistenceBroker();
> broker.clearCache();
> broker.close();
> PersistenceBrokerFactory.releaseAllInstances();
> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>
> PersistenceBrokerThreadMapping.shutdown();
> PersistenceBrokerFactoryFactory.instance().shutdown();
> PersistenceBrokerFactory.shutdown();
>
> Rick Roman wrote:
>
>> You were correct. I had a ghost version of 1.0.3 in my path. Thanks.
>>
>> Antonio Gallardo wrote:
>>
>>> hi,
>>>
>>> Seems like an class loader issue. Can you check if there are not
>>> older ojb.jar in your classpath loaded before the ojb 1.0.4?
>>>
>>> Best Regards,
>>>
>>> Antonio Gallardo.
>>>
>>> Rick Roman wrote:
>>>
>>>> I upgraded to the new db-ojb-1.0.4 which has the method
>>>>
>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>
>>>> This results in exception:
>>>>
>>>> [ERROR] mffweb] - Exception sending context destroyed event to
>>>> listener instance of class org.mff.web.listener.CleanupListener
>>>> <java.lang.NoSuchMethodError:
>>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>>>> at
>>>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>>>
>>>>
>>>> Still have memory leak or (I suppose more accurtately, failure to
>>>> clean up resources). Anyone have any ideas or has anyone ever
>>>> actually been able to avoid this problem or am I just stuck with it?
>>>>
>>>>
>>>> Armin Waibel wrote:
>>>>
>>>>> Hi Rick,
>>>>>
>>>>> Rick Roman wrote:
>>>>>
>>>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating
>>>>>> it.
>>>>>>
>>>>>
>>>>> Think this will not work, because the changes will affect other
>>>>> classes too.
>>>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>>>
>>>>> I recommend to use the latest from OJB 1.0.x branch
>>>>> (OJB_1_0_RELEASE branch, trunk is unstable 1.x). The 1.0.x branch
>>>>> is 95% stable (the test-suite show some odmg-api specific test
>>>>> failures, will be fixed soon).
>>>>>
>>>>> regards,
>>>>> Armin
>>>>>
>>>>>
>>>>>> Ilkka Priha wrote:
>>>>>>
>>>>>>> Rick,
>>>>>>>
>>>>>>> It was introduced in revision 1.4.2.2 of
>>>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>>>
>>>>>>> -- Ilkka
>>>>>>>
>>>>>>> /**
>>>>>>> * Shutdown method for OJB, kills all running processes within
>>>>>>> OJB - after
>>>>>>> * shutdown OJB can no longer be used.
>>>>>>> * <br/>
>>>>>>> * This method is introduced to solve hot/redeployment problems
>>>>>>> (memory leaks) caused by
>>>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>>>> the reuse of threads
>>>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>>>> */
>>>>>>> public void shutdown();
>>>>>>>
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> Hi Ilkka,
>>>>>>>>
>>>>>>>> shutdown() does not appear to be a method of
>>>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch
>>>>>>>> with this available?
>>>>>>>>
>>>>>>>> Ilkka Priha wrote:
>>>>>>>>
>>>>>>>>> Hi Rick,
>>>>>>>>>
>>>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>>>
>>>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>>>
>>>>>>>>> -- Ilkka
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Rick Roman wrote:
>>>>>>>>>
>>>>>>>>>> Update: From other threads, I have tried using a
>>>>>>>>>> contextDestroy listener to run:
>>>>>>>>>>
>>>>>>>>>> PersistenceBroker broker =
>>>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>>>> broker.clearCache();
>>>>>>>>>> broker.close();
>>>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>>>
>>>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>>>
>>>>>>>>>> and the leak still persists.
>>>>>>>>>>
>>>>>>>>>> Rick Roman wrote:
>>>>>>>>>>
>>>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>>>> error. I believe this has to do with my OBJ configuration as
>>>>>>>>>>> I am able to access the datasource without OBJ and I don't
>>>>>>>>>>> see the problem. The memory leak problem is a known issue,
>>>>>>>>>>> discussed in detail here:
>>>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>>>> In short, the problem is that "if any object that is loaded
>>>>>>>>>>> by the system or container classloader (StandardClassLoader
>>>>>>>>>>> in tomcat) still has a reference to the application class
>>>>>>>>>>> loader or any object loaded by it, the class loader will not
>>>>>>>>>>> be garbage collected. In that case, all the class objects and
>>>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>>>
>>>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>>>
>>>>>>>>>>> repository.xml
>>>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>>>> jcd-alias="default"
>>>>>>>>>>> default-connection="true"
>>>>>>>>>>> platform="PostgreSQL"
>>>>>>>>>>> jdbc-level="3.0"
>>>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>>>> eager-release="false"
>>>>>>>>>>> batch-mode="false"
>>>>>>>>>>> useAutoCommit="1"
>>>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>>>> attribute-value=""/>
>>>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>>>> attribute-value="900"/>
>>>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>>>> attribute-value="true"/>
>>>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>>>> attribute-value="0"/>
>>>>>>>>>>> </object-cache>
>>>>>>>>>>> <sequence-manager
>>>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>>>
>>>>>>>>>>> </sequence-manager>
>>>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>>>
>>>>>>>>>>> OBJ.properties
>>>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>>>> useSerializedRepository=false
>>>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>>>
>>>>>>>>>>> maxActive=256
>>>>>>>>>>> maxIdle=-1
>>>>>>>>>>> maxWait=2000
>>>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>>>> whenExhaustedAction=0
>>>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>>>
>>>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>>>
>>>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>>>
>>>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>>>
>>>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>>>
>>>>>>>>>>> LockTimeout=60000
>>>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>>>
>>>>>>>>>>> SqlInLimit=200
>>>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>>>> ImplicitLocking=true
>>>>>>>>>>> LockAssociations=WRITE
>>>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>>>
>>>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
OK I'm really on version 1.0.4 now and all of these methods run without
error. Unfortunately, none of them have any effect on the memory leak.
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.clearCache();
broker.close();
PersistenceBrokerFactory.releaseAllInstances();
ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
PersistenceBrokerThreadMapping.shutdown();
PersistenceBrokerFactoryFactory.instance().shutdown();
PersistenceBrokerFactory.shutdown();
Rick Roman wrote:
> You were correct. I had a ghost version of 1.0.3 in my path. Thanks.
>
> Antonio Gallardo wrote:
>
>> hi,
>>
>> Seems like an class loader issue. Can you check if there are not
>> older ojb.jar in your classpath loaded before the ojb 1.0.4?
>>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
>> Rick Roman wrote:
>>
>>> I upgraded to the new db-ojb-1.0.4 which has the method
>>>
>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>
>>> This results in exception:
>>>
>>> [ERROR] mffweb] - Exception sending context destroyed event to
>>> listener instance of class org.mff.web.listener.CleanupListener
>>> <java.lang.NoSuchMethodError:
>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>>> at
>>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>>
>>>
>>> Still have memory leak or (I suppose more accurtately, failure to
>>> clean up resources). Anyone have any ideas or has anyone ever
>>> actually been able to avoid this problem or am I just stuck with it?
>>>
>>>
>>> Armin Waibel wrote:
>>>
>>>> Hi Rick,
>>>>
>>>> Rick Roman wrote:
>>>>
>>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating
>>>>> it.
>>>>>
>>>>
>>>> Think this will not work, because the changes will affect other
>>>> classes too.
>>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>>
>>>> I recommend to use the latest from OJB 1.0.x branch
>>>> (OJB_1_0_RELEASE branch, trunk is unstable 1.x). The 1.0.x branch
>>>> is 95% stable (the test-suite show some odmg-api specific test
>>>> failures, will be fixed soon).
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>
>>>>> Ilkka Priha wrote:
>>>>>
>>>>>> Rick,
>>>>>>
>>>>>> It was introduced in revision 1.4.2.2 of
>>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>>
>>>>>> -- Ilkka
>>>>>>
>>>>>> /**
>>>>>> * Shutdown method for OJB, kills all running processes within
>>>>>> OJB - after
>>>>>> * shutdown OJB can no longer be used.
>>>>>> * <br/>
>>>>>> * This method is introduced to solve hot/redeployment problems
>>>>>> (memory leaks) caused by
>>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>>> the reuse of threads
>>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>>> */
>>>>>> public void shutdown();
>>>>>>
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> Hi Ilkka,
>>>>>>>
>>>>>>> shutdown() does not appear to be a method of
>>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch
>>>>>>> with this available?
>>>>>>>
>>>>>>> Ilkka Priha wrote:
>>>>>>>
>>>>>>>> Hi Rick,
>>>>>>>>
>>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>>
>>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>>
>>>>>>>> -- Ilkka
>>>>>>>>
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> Update: From other threads, I have tried using a
>>>>>>>>> contextDestroy listener to run:
>>>>>>>>>
>>>>>>>>> PersistenceBroker broker =
>>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>>> broker.clearCache();
>>>>>>>>> broker.close();
>>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>>
>>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>>
>>>>>>>>> and the leak still persists.
>>>>>>>>>
>>>>>>>>> Rick Roman wrote:
>>>>>>>>>
>>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>>> error. I believe this has to do with my OBJ configuration as
>>>>>>>>>> I am able to access the datasource without OBJ and I don't
>>>>>>>>>> see the problem. The memory leak problem is a known issue,
>>>>>>>>>> discussed in detail here:
>>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>>> In short, the problem is that "if any object that is loaded
>>>>>>>>>> by the system or container classloader (StandardClassLoader
>>>>>>>>>> in tomcat) still has a reference to the application class
>>>>>>>>>> loader or any object loaded by it, the class loader will not
>>>>>>>>>> be garbage collected. In that case, all the class objects and
>>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>>
>>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>>
>>>>>>>>>> repository.xml
>>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>>> jcd-alias="default"
>>>>>>>>>> default-connection="true"
>>>>>>>>>> platform="PostgreSQL"
>>>>>>>>>> jdbc-level="3.0"
>>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>>> eager-release="false"
>>>>>>>>>> batch-mode="false"
>>>>>>>>>> useAutoCommit="1"
>>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>>> attribute-value=""/>
>>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>>> attribute-value="900"/>
>>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>>> attribute-value="true"/>
>>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>>> attribute-value="0"/>
>>>>>>>>>> </object-cache>
>>>>>>>>>> <sequence-manager
>>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>>
>>>>>>>>>> </sequence-manager>
>>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>>
>>>>>>>>>> OBJ.properties
>>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>>> useSerializedRepository=false
>>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>>
>>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>>
>>>>>>>>>> maxActive=256
>>>>>>>>>> maxIdle=-1
>>>>>>>>>> maxWait=2000
>>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>>> whenExhaustedAction=0
>>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>>
>>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>>
>>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>>
>>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>>
>>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>>
>>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>>
>>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>>
>>>>>>>>>> LockTimeout=60000
>>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>>
>>>>>>>>>> SqlInLimit=200
>>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>>> ImplicitLocking=true
>>>>>>>>>> LockAssociations=WRITE
>>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>>
>>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
You were correct. I had a ghost version of 1.0.3 in my path. Thanks.
Antonio Gallardo wrote:
> hi,
>
> Seems like an class loader issue. Can you check if there are not older
> ojb.jar in your classpath loaded before the ojb 1.0.4?
>
> Best Regards,
>
> Antonio Gallardo.
>
> Rick Roman wrote:
>
>> I upgraded to the new db-ojb-1.0.4 which has the method
>>
>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>
>> This results in exception:
>>
>> [ERROR] mffweb] - Exception sending context destroyed event to
>> listener instance of class org.mff.web.listener.CleanupListener
>> <java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>> at
>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>
>>
>> Still have memory leak or (I suppose more accurtately, failure to
>> clean up resources). Anyone have any ideas or has anyone ever
>> actually been able to avoid this problem or am I just stuck with it?
>>
>>
>> Armin Waibel wrote:
>>
>>> Hi Rick,
>>>
>>> Rick Roman wrote:
>>>
>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>>
>>>
>>> Think this will not work, because the changes will affect other
>>> classes too.
>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>
>>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>>> test-suite show some odmg-api specific test failures, will be fixed
>>> soon).
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Ilkka Priha wrote:
>>>>
>>>>> Rick,
>>>>>
>>>>> It was introduced in revision 1.4.2.2 of
>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>
>>>>> -- Ilkka
>>>>>
>>>>> /**
>>>>> * Shutdown method for OJB, kills all running processes within OJB
>>>>> - after
>>>>> * shutdown OJB can no longer be used.
>>>>> * <br/>
>>>>> * This method is introduced to solve hot/redeployment problems
>>>>> (memory leaks) caused by
>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>> the reuse of threads
>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>> */
>>>>> public void shutdown();
>>>>>
>>>>>
>>>>> Rick Roman wrote:
>>>>>
>>>>>> Hi Ilkka,
>>>>>>
>>>>>> shutdown() does not appear to be a method of
>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>>> this available?
>>>>>>
>>>>>> Ilkka Priha wrote:
>>>>>>
>>>>>>> Hi Rick,
>>>>>>>
>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>
>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>
>>>>>>> -- Ilkka
>>>>>>>
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>>> listener to run:
>>>>>>>>
>>>>>>>> PersistenceBroker broker =
>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>> broker.clearCache();
>>>>>>>> broker.close();
>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>
>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>
>>>>>>>> and the leak still persists.
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>> error. I believe this has to do with my OBJ configuration as I
>>>>>>>>> am able to access the datasource without OBJ and I don't see
>>>>>>>>> the problem. The memory leak problem is a known issue,
>>>>>>>>> discussed in detail here:
>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>>> tomcat) still has a reference to the application class loader
>>>>>>>>> or any object loaded by it, the class loader will not be
>>>>>>>>> garbage collected. In that case, all the class objects and
>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>
>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>
>>>>>>>>> repository.xml
>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>> jcd-alias="default"
>>>>>>>>> default-connection="true"
>>>>>>>>> platform="PostgreSQL"
>>>>>>>>> jdbc-level="3.0"
>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>> eager-release="false"
>>>>>>>>> batch-mode="false"
>>>>>>>>> useAutoCommit="1"
>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>> attribute-value=""/>
>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>> attribute-value="900"/>
>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>> attribute-value="true"/>
>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>> attribute-value="0"/>
>>>>>>>>> </object-cache>
>>>>>>>>> <sequence-manager
>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>
>>>>>>>>> </sequence-manager>
>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>
>>>>>>>>> OBJ.properties
>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>> useSerializedRepository=false
>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>
>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>
>>>>>>>>> maxActive=256
>>>>>>>>> maxIdle=-1
>>>>>>>>> maxWait=2000
>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>> whenExhaustedAction=0
>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>
>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>
>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>
>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>
>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>
>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>
>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>
>>>>>>>>> LockTimeout=60000
>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>
>>>>>>>>> SqlInLimit=200
>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>> ImplicitLocking=true
>>>>>>>>> LockAssociations=WRITE
>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>
>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Antonio Gallardo <ag...@agssa.net>.
hi,
Seems like an class loader issue. Can you check if there are not older
ojb.jar in your classpath loaded before the ojb 1.0.4?
Best Regards,
Antonio Gallardo.
Rick Roman wrote:
> I upgraded to the new db-ojb-1.0.4 which has the method
>
> PersistenceBrokerFactoryFactory.instance().shutdown();
>
> This results in exception:
>
> [ERROR] mffweb] - Exception sending context destroyed event to
> listener instance of class org.mff.web.listener.CleanupListener
> <java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
> at
> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>
>
> Still have memory leak or (I suppose more accurtately, failure to
> clean up resources). Anyone have any ideas or has anyone ever actually
> been able to avoid this problem or am I just stuck with it?
>
>
> Armin Waibel wrote:
>
>> Hi Rick,
>>
>> Rick Roman wrote:
>>
>>> Sorry to be dense but can you send me the link to cvs for revision
>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>
>>
>> Think this will not work, because the changes will affect other
>> classes too.
>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>
>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>> test-suite show some odmg-api specific test failures, will be fixed
>> soon).
>>
>> regards,
>> Armin
>>
>>
>>> Ilkka Priha wrote:
>>>
>>>> Rick,
>>>>
>>>> It was introduced in revision 1.4.2.2 of PersistenceBrokerFactoryIF
>>>> (25/07/05), so it's available only in the cvs version of OJB, but
>>>> hopefully quite soon also as 1.0.4-rc.
>>>>
>>>> -- Ilkka
>>>>
>>>> /**
>>>> * Shutdown method for OJB, kills all running processes within OJB
>>>> - after
>>>> * shutdown OJB can no longer be used.
>>>> * <br/>
>>>> * This method is introduced to solve hot/redeployment problems
>>>> (memory leaks) caused by
>>>> * the usage of {@link ThreadLocal} instances in OJB source and the
>>>> reuse of threads
>>>> * by the container (e.g. servlet- or ejb-container).
>>>> */
>>>> public void shutdown();
>>>>
>>>>
>>>> Rick Roman wrote:
>>>>
>>>>> Hi Ilkka,
>>>>>
>>>>> shutdown() does not appear to be a method of
>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>> this available?
>>>>>
>>>>> Ilkka Priha wrote:
>>>>>
>>>>>> Hi Rick,
>>>>>>
>>>>>> Have you tried this one, it alone should do the job.
>>>>>>
>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>
>>>>>> -- Ilkka
>>>>>>
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>> listener to run:
>>>>>>>
>>>>>>> PersistenceBroker broker =
>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>> broker.clearCache();
>>>>>>> broker.close();
>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>
>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>
>>>>>>> and the leak still persists.
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>> reloads, tomcat eventually crashes with an out of memory error.
>>>>>>>> I believe this has to do with my OBJ configuration as I am able
>>>>>>>> to access the datasource without OBJ and I don't see the
>>>>>>>> problem. The memory leak problem is a known issue, discussed in
>>>>>>>> detail here:
>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>> tomcat) still has a reference to the application class loader
>>>>>>>> or any object loaded by it, the class loader will not be
>>>>>>>> garbage collected. In that case, all the class objects and
>>>>>>>> every object referenced by a static field in any of the classes
>>>>>>>> will not be garbage collected."
>>>>>>>>
>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>
>>>>>>>> repository.xml
>>>>>>>> <jdbc-connection-descriptor
>>>>>>>> jcd-alias="default"
>>>>>>>> default-connection="true"
>>>>>>>> platform="PostgreSQL"
>>>>>>>> jdbc-level="3.0"
>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>> eager-release="false"
>>>>>>>> batch-mode="false"
>>>>>>>> useAutoCommit="1"
>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>> attribute-value=""/>
>>>>>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>> attribute-value="true"/>
>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>> attribute-value="0"/>
>>>>>>>> </object-cache>
>>>>>>>> <sequence-manager
>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>
>>>>>>>> </sequence-manager>
>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>
>>>>>>>> OBJ.properties
>>>>>>>> repositoryFile=repository.xml
>>>>>>>> useSerializedRepository=false
>>>>>>>> serializedRepositoryPath=.
>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>
>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>
>>>>>>>> maxActive=256
>>>>>>>> maxIdle=-1
>>>>>>>> maxWait=2000
>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>> whenExhaustedAction=0
>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>
>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>
>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>
>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>
>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>
>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>
>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>
>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>
>>>>>>>> descriptorBasedCaches=false
>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>
>>>>>>>> LockTimeout=60000
>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>
>>>>>>>> SqlInLimit=200
>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>> cascadingDeleteMToN=false
>>>>>>>> ImplicitLocking=true
>>>>>>>> LockAssociations=WRITE
>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>
>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by "Craig A. Vanderborgh" <cr...@voxware.com>.
Hello:
Sun JDK has some quite terrible memory leaks that are "known
problems". Here are the pertinent Sun bug entries:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5033614 (fixed, but in 1.5, not 1.4!)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990 (unfixed)
Basically, you will find that these memory leaks on webapp context redeploy exist independently of the infrastructure used. That is to say - OJB may or may not have memory leaks on webapp redeploy, but such leaks pale in comparison to the "classloader leaks" that are inherent in Sun's current JVM release(s) itself.
The problem is a truly terrible one. And there is a solution which I hope you will be open to... because the only other real alternative is to just "live with" the memory leaks. The solution is to use a different JVM. BEA's JRockit does not have these "classloader" memory leaks. We have verified this, and have REPLACED the faulty Sun JVM in our application.
You can learn more about "JRockit" - a fully compliant JVM that WORKS - here:
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/jrockit/
I hope you will at least try it. The difference is night & day...
Hth,
craig vanderborgh
voxware incorporated
Armin Waibel wrote:
> Hi Rick,
>
> Rick Roman wrote:
>
>> I upgraded to the new db-ojb-1.0.4 which has the method
>>
>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>
>> This results in exception:
>>
>> [ERROR] mffweb] - Exception sending context destroyed event to
>> listener instance of class org.mff.web.listener.CleanupListener
>> <java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>> at
>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>
>
>
> Did you really replace all old OJB jars?
> This method exists in PersistenceBrokerThreadMapping and will be
> called when PersistenceBrokerFactory.shutdown() was called.
>
> regards,
> Armin
>
>
>>
>> Still have memory leak or (I suppose more accurtately, failure to
>> clean up resources). Anyone have any ideas or has anyone ever
>> actually been able to avoid this problem or am I just stuck with it?
>>
>>
>> Armin Waibel wrote:
>>
>>> Hi Rick,
>>>
>>> Rick Roman wrote:
>>>
>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>>
>>>
>>> Think this will not work, because the changes will affect other
>>> classes too.
>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>
>>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>>> test-suite show some odmg-api specific test failures, will be fixed
>>> soon).
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Ilkka Priha wrote:
>>>>
>>>>> Rick,
>>>>>
>>>>> It was introduced in revision 1.4.2.2 of
>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>
>>>>> -- Ilkka
>>>>>
>>>>> /**
>>>>> * Shutdown method for OJB, kills all running processes within OJB
>>>>> - after
>>>>> * shutdown OJB can no longer be used.
>>>>> * <br/>
>>>>> * This method is introduced to solve hot/redeployment problems
>>>>> (memory leaks) caused by
>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>> the reuse of threads
>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>> */
>>>>> public void shutdown();
>>>>>
>>>>>
>>>>> Rick Roman wrote:
>>>>>
>>>>>> Hi Ilkka,
>>>>>>
>>>>>> shutdown() does not appear to be a method of
>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>>> this available?
>>>>>>
>>>>>> Ilkka Priha wrote:
>>>>>>
>>>>>>> Hi Rick,
>>>>>>>
>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>
>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>
>>>>>>> -- Ilkka
>>>>>>>
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>>> listener to run:
>>>>>>>>
>>>>>>>> PersistenceBroker broker =
>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>> broker.clearCache();
>>>>>>>> broker.close();
>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>
>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>
>>>>>>>> and the leak still persists.
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>> error. I believe this has to do with my OBJ configuration as I
>>>>>>>>> am able to access the datasource without OBJ and I don't see
>>>>>>>>> the problem. The memory leak problem is a known issue,
>>>>>>>>> discussed in detail here:
>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>>> tomcat) still has a reference to the application class loader
>>>>>>>>> or any object loaded by it, the class loader will not be
>>>>>>>>> garbage collected. In that case, all the class objects and
>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>
>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>
>>>>>>>>> repository.xml
>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>> jcd-alias="default"
>>>>>>>>> default-connection="true"
>>>>>>>>> platform="PostgreSQL"
>>>>>>>>> jdbc-level="3.0"
>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>> eager-release="false"
>>>>>>>>> batch-mode="false"
>>>>>>>>> useAutoCommit="1"
>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>> attribute-value=""/>
>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>> attribute-value="900"/>
>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>> attribute-value="true"/>
>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>> attribute-value="0"/>
>>>>>>>>> </object-cache>
>>>>>>>>> <sequence-manager
>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>
>>>>>>>>> </sequence-manager>
>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>
>>>>>>>>> OBJ.properties
>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>> useSerializedRepository=false
>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>
>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>
>>>>>>>>> maxActive=256
>>>>>>>>> maxIdle=-1
>>>>>>>>> maxWait=2000
>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>> whenExhaustedAction=0
>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>
>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>
>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>
>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>
>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>
>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>
>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>
>>>>>>>>> LockTimeout=60000
>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>
>>>>>>>>> SqlInLimit=200
>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>> ImplicitLocking=true
>>>>>>>>> LockAssociations=WRITE
>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>
>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Armin Waibel <ar...@apache.org>.
Rick Roman wrote:
> Hi Armin. I don't have all the jars from the distribution lib directory
> but I have all those with ojb in the name plus all the common- Should I
> have them all?
>
> I tried calling PersistenceBrokerFactory.shutdown() instead and got a
> similar error.
>
> Exception sending context destroyed event to listener instance of class
> org.mff.web.listener.CleanupListener <java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>
This is really strange! I downloaded the 1.0.4 source jar, this include
PersistenceBrokerThreadMapping.shutdown() method.
http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/core/PersistenceBrokerThreadMapping.java?rev=365232&view=markup
Normally it's not necessary to directly call this method, simply call
PersistenceBrokerFactory.shutdown();
This will cascade all shutdown() method calls.
regards,
Armin
>
>
>
> Armin Waibel wrote:
>
>> Hi Rick,
>>
>> Rick Roman wrote:
>>
>>> I upgraded to the new db-ojb-1.0.4 which has the method
>>>
>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>
>>> This results in exception:
>>>
>>> [ERROR] mffweb] - Exception sending context destroyed event to
>>> listener instance of class org.mff.web.listener.CleanupListener
>>> <java.lang.NoSuchMethodError:
>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>>> at
>>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>>
>>
>>
>>
>> Did you really replace all old OJB jars?
>> This method exists in PersistenceBrokerThreadMapping and will be
>> called when PersistenceBrokerFactory.shutdown() was called.
>>
>> regards,
>> Armin
>>
>>
>>>
>>> Still have memory leak or (I suppose more accurtately, failure to
>>> clean up resources). Anyone have any ideas or has anyone ever
>>> actually been able to avoid this problem or am I just stuck with it?
>>>
>>>
>>> Armin Waibel wrote:
>>>
>>>> Hi Rick,
>>>>
>>>> Rick Roman wrote:
>>>>
>>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>>>
>>>>
>>>> Think this will not work, because the changes will affect other
>>>> classes too.
>>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>>
>>>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>>>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>>>> test-suite show some odmg-api specific test failures, will be fixed
>>>> soon).
>>>>
>>>> regards,
>>>> Armin
>>>>
>>>>
>>>>> Ilkka Priha wrote:
>>>>>
>>>>>> Rick,
>>>>>>
>>>>>> It was introduced in revision 1.4.2.2 of
>>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>>
>>>>>> -- Ilkka
>>>>>>
>>>>>> /**
>>>>>> * Shutdown method for OJB, kills all running processes within OJB
>>>>>> - after
>>>>>> * shutdown OJB can no longer be used.
>>>>>> * <br/>
>>>>>> * This method is introduced to solve hot/redeployment problems
>>>>>> (memory leaks) caused by
>>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>>> the reuse of threads
>>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>>> */
>>>>>> public void shutdown();
>>>>>>
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> Hi Ilkka,
>>>>>>>
>>>>>>> shutdown() does not appear to be a method of
>>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>>>> this available?
>>>>>>>
>>>>>>> Ilkka Priha wrote:
>>>>>>>
>>>>>>>> Hi Rick,
>>>>>>>>
>>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>>
>>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>>
>>>>>>>> -- Ilkka
>>>>>>>>
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>>>> listener to run:
>>>>>>>>>
>>>>>>>>> PersistenceBroker broker =
>>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>>> broker.clearCache();
>>>>>>>>> broker.close();
>>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>>
>>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>>
>>>>>>>>> and the leak still persists.
>>>>>>>>>
>>>>>>>>> Rick Roman wrote:
>>>>>>>>>
>>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>>> error. I believe this has to do with my OBJ configuration as I
>>>>>>>>>> am able to access the datasource without OBJ and I don't see
>>>>>>>>>> the problem. The memory leak problem is a known issue,
>>>>>>>>>> discussed in detail here:
>>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>>>> tomcat) still has a reference to the application class loader
>>>>>>>>>> or any object loaded by it, the class loader will not be
>>>>>>>>>> garbage collected. In that case, all the class objects and
>>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>>
>>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>>
>>>>>>>>>> repository.xml
>>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>>> jcd-alias="default"
>>>>>>>>>> default-connection="true"
>>>>>>>>>> platform="PostgreSQL"
>>>>>>>>>> jdbc-level="3.0"
>>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>>> eager-release="false"
>>>>>>>>>> batch-mode="false"
>>>>>>>>>> useAutoCommit="1"
>>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>>> attribute-value=""/>
>>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>>> attribute-value="900"/>
>>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>>> attribute-value="true"/>
>>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>>> attribute-value="0"/>
>>>>>>>>>> </object-cache>
>>>>>>>>>> <sequence-manager
>>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>>
>>>>>>>>>> </sequence-manager>
>>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>>
>>>>>>>>>> OBJ.properties
>>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>>> useSerializedRepository=false
>>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>>
>>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>>
>>>>>>>>>> maxActive=256
>>>>>>>>>> maxIdle=-1
>>>>>>>>>> maxWait=2000
>>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>>> whenExhaustedAction=0
>>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>>
>>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>>
>>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>>
>>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>>
>>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>>
>>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>>
>>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>>
>>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>>
>>>>>>>>>> LockTimeout=60000
>>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>>
>>>>>>>>>> SqlInLimit=200
>>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>>> ImplicitLocking=true
>>>>>>>>>> LockAssociations=WRITE
>>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>>
>>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Rick Roman <ri...@cotse.net>.
Hi Armin. I don't have all the jars from the distribution lib directory
but I have all those with ojb in the name plus all the common- Should I
have them all?
I tried calling PersistenceBrokerFactory.shutdown() instead and got a
similar error.
Exception sending context destroyed event to listener instance of class
org.mff.web.listener.CleanupListener <java.lang.NoSuchMethodError:
org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
Armin Waibel wrote:
> Hi Rick,
>
> Rick Roman wrote:
>
>> I upgraded to the new db-ojb-1.0.4 which has the method
>>
>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>
>> This results in exception:
>>
>> [ERROR] mffweb] - Exception sending context destroyed event to
>> listener instance of class org.mff.web.listener.CleanupListener
>> <java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
>> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
>> at
>> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>>
>
>
> Did you really replace all old OJB jars?
> This method exists in PersistenceBrokerThreadMapping and will be
> called when PersistenceBrokerFactory.shutdown() was called.
>
> regards,
> Armin
>
>
>>
>> Still have memory leak or (I suppose more accurtately, failure to
>> clean up resources). Anyone have any ideas or has anyone ever
>> actually been able to avoid this problem or am I just stuck with it?
>>
>>
>> Armin Waibel wrote:
>>
>>> Hi Rick,
>>>
>>> Rick Roman wrote:
>>>
>>>> Sorry to be dense but can you send me the link to cvs for revision
>>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>>
>>>
>>> Think this will not work, because the changes will affect other
>>> classes too.
>>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>>
>>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>>> test-suite show some odmg-api specific test failures, will be fixed
>>> soon).
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Ilkka Priha wrote:
>>>>
>>>>> Rick,
>>>>>
>>>>> It was introduced in revision 1.4.2.2 of
>>>>> PersistenceBrokerFactoryIF (25/07/05), so it's available only in
>>>>> the cvs version of OJB, but hopefully quite soon also as 1.0.4-rc.
>>>>>
>>>>> -- Ilkka
>>>>>
>>>>> /**
>>>>> * Shutdown method for OJB, kills all running processes within OJB
>>>>> - after
>>>>> * shutdown OJB can no longer be used.
>>>>> * <br/>
>>>>> * This method is introduced to solve hot/redeployment problems
>>>>> (memory leaks) caused by
>>>>> * the usage of {@link ThreadLocal} instances in OJB source and
>>>>> the reuse of threads
>>>>> * by the container (e.g. servlet- or ejb-container).
>>>>> */
>>>>> public void shutdown();
>>>>>
>>>>>
>>>>> Rick Roman wrote:
>>>>>
>>>>>> Hi Ilkka,
>>>>>>
>>>>>> shutdown() does not appear to be a method of
>>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>>> this available?
>>>>>>
>>>>>> Ilkka Priha wrote:
>>>>>>
>>>>>>> Hi Rick,
>>>>>>>
>>>>>>> Have you tried this one, it alone should do the job.
>>>>>>>
>>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>>
>>>>>>> -- Ilkka
>>>>>>>
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>>> listener to run:
>>>>>>>>
>>>>>>>> PersistenceBroker broker =
>>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>>> broker.clearCache();
>>>>>>>> broker.close();
>>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>>
>>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>>
>>>>>>>> and the leak still persists.
>>>>>>>>
>>>>>>>> Rick Roman wrote:
>>>>>>>>
>>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>>> reloads, tomcat eventually crashes with an out of memory
>>>>>>>>> error. I believe this has to do with my OBJ configuration as I
>>>>>>>>> am able to access the datasource without OBJ and I don't see
>>>>>>>>> the problem. The memory leak problem is a known issue,
>>>>>>>>> discussed in detail here:
>>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>>> tomcat) still has a reference to the application class loader
>>>>>>>>> or any object loaded by it, the class loader will not be
>>>>>>>>> garbage collected. In that case, all the class objects and
>>>>>>>>> every object referenced by a static field in any of the
>>>>>>>>> classes will not be garbage collected."
>>>>>>>>>
>>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>>
>>>>>>>>> repository.xml
>>>>>>>>> <jdbc-connection-descriptor
>>>>>>>>> jcd-alias="default"
>>>>>>>>> default-connection="true"
>>>>>>>>> platform="PostgreSQL"
>>>>>>>>> jdbc-level="3.0"
>>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>>> eager-release="false"
>>>>>>>>> batch-mode="false"
>>>>>>>>> useAutoCommit="1"
>>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>>> attribute-value=""/>
>>>>>>>>> <attribute attribute-name="timeout"
>>>>>>>>> attribute-value="900"/>
>>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>>> attribute-value="true"/>
>>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>>> attribute-value="0"/>
>>>>>>>>> </object-cache>
>>>>>>>>> <sequence-manager
>>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>>
>>>>>>>>> </sequence-manager>
>>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>>
>>>>>>>>> OBJ.properties
>>>>>>>>> repositoryFile=repository.xml
>>>>>>>>> useSerializedRepository=false
>>>>>>>>> serializedRepositoryPath=.
>>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>>
>>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>>
>>>>>>>>> maxActive=256
>>>>>>>>> maxIdle=-1
>>>>>>>>> maxWait=2000
>>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>>> whenExhaustedAction=0
>>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>>
>>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>>
>>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>>
>>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>>
>>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>>
>>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>>
>>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>>
>>>>>>>>> descriptorBasedCaches=false
>>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>>
>>>>>>>>> LockTimeout=60000
>>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>>
>>>>>>>>> SqlInLimit=200
>>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>>> cascadingDeleteMToN=false
>>>>>>>>> ImplicitLocking=true
>>>>>>>>> LockAssociations=WRITE
>>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>>
>>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Tomcat 5, JNDI, Perm Gen Memory leak
Posted by Armin Waibel <ar...@apache.org>.
Hi Rick,
Rick Roman wrote:
> I upgraded to the new db-ojb-1.0.4 which has the method
>
> PersistenceBrokerFactoryFactory.instance().shutdown();
>
> This results in exception:
>
> [ERROR] mffweb] - Exception sending context destroyed event to listener
> instance of class org.mff.web.listener.CleanupListener
> <java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V>java.lang.NoSuchMethodError:
> org.apache.ojb.broker.core.PersistenceBrokerThreadMapping.shutdown()V
> at
> org.mff.web.listener.CleanupListener.contextDestroyed(CleanupListener.java:59)
>
Did you really replace all old OJB jars?
This method exists in PersistenceBrokerThreadMapping and will be called
when PersistenceBrokerFactory.shutdown() was called.
regards,
Armin
>
> Still have memory leak or (I suppose more accurtately, failure to clean
> up resources). Anyone have any ideas or has anyone ever actually been
> able to avoid this problem or am I just stuck with it?
>
>
> Armin Waibel wrote:
>
>> Hi Rick,
>>
>> Rick Roman wrote:
>>
>>> Sorry to be dense but can you send me the link to cvs for revision
>>> 1.4.2.2 of PersistenceBrokerFactoryIF? I'm having trouble locating it.
>>>
>>
>> Think this will not work, because the changes will affect other
>> classes too.
>> http://www.mail-archive.com/ojb-dev@db.apache.org/msg01553.html
>>
>> I recommend to use the latest from OJB 1.0.x branch (OJB_1_0_RELEASE
>> branch, trunk is unstable 1.x). The 1.0.x branch is 95% stable (the
>> test-suite show some odmg-api specific test failures, will be fixed
>> soon).
>>
>> regards,
>> Armin
>>
>>
>>> Ilkka Priha wrote:
>>>
>>>> Rick,
>>>>
>>>> It was introduced in revision 1.4.2.2 of PersistenceBrokerFactoryIF
>>>> (25/07/05), so it's available only in the cvs version of OJB, but
>>>> hopefully quite soon also as 1.0.4-rc.
>>>>
>>>> -- Ilkka
>>>>
>>>> /**
>>>> * Shutdown method for OJB, kills all running processes within OJB -
>>>> after
>>>> * shutdown OJB can no longer be used.
>>>> * <br/>
>>>> * This method is introduced to solve hot/redeployment problems
>>>> (memory leaks) caused by
>>>> * the usage of {@link ThreadLocal} instances in OJB source and the
>>>> reuse of threads
>>>> * by the container (e.g. servlet- or ejb-container).
>>>> */
>>>> public void shutdown();
>>>>
>>>>
>>>> Rick Roman wrote:
>>>>
>>>>> Hi Ilkka,
>>>>>
>>>>> shutdown() does not appear to be a method of
>>>>> PersistenceBrokerFactoryFactory.instance(). Is there a patch with
>>>>> this available?
>>>>>
>>>>> Ilkka Priha wrote:
>>>>>
>>>>>> Hi Rick,
>>>>>>
>>>>>> Have you tried this one, it alone should do the job.
>>>>>>
>>>>>> PersistenceBrokerFactoryFactory.instance().shutdown();
>>>>>>
>>>>>> -- Ilkka
>>>>>>
>>>>>>
>>>>>> Rick Roman wrote:
>>>>>>
>>>>>>> Update: From other threads, I have tried using a contextDestroy
>>>>>>> listener to run:
>>>>>>>
>>>>>>> PersistenceBroker broker =
>>>>>>> PersistenceBrokerFactory.defaultPersistenceBroker();
>>>>>>> broker.clearCache();
>>>>>>> broker.close();
>>>>>>> PersistenceBrokerFactory.releaseAllInstances();
>>>>>>> ConnectionFactoryFactory.getInstance().createConnectionFactory().releaseAllResources();
>>>>>>>
>>>>>>> PersistenceBrokerThreadMapping.shutdown();
>>>>>>> MetadataManager.getInstance().removeAllProfiles();
>>>>>>>
>>>>>>> and the leak still persists.
>>>>>>>
>>>>>>> Rick Roman wrote:
>>>>>>>
>>>>>>>> I am using OBJ to access PostgreSQL via a JNDI datasource. My
>>>>>>>> problem is that every time I reload my application context, I
>>>>>>>> get a big jump in Tomcat Perm Gen memory. After a several
>>>>>>>> reloads, tomcat eventually crashes with an out of memory error.
>>>>>>>> I believe this has to do with my OBJ configuration as I am able
>>>>>>>> to access the datasource without OBJ and I don't see the
>>>>>>>> problem. The memory leak problem is a known issue, discussed in
>>>>>>>> detail here:
>>>>>>>> http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
>>>>>>>> In short, the problem is that "if any object that is loaded by
>>>>>>>> the system or container classloader (StandardClassLoader in
>>>>>>>> tomcat) still has a reference to the application class loader or
>>>>>>>> any object loaded by it, the class loader will not be garbage
>>>>>>>> collected. In that case, all the class objects and every object
>>>>>>>> referenced by a static field in any of the classes will not be
>>>>>>>> garbage collected."
>>>>>>>>
>>>>>>>> Does anyone know how I can get rid of this behavior?
>>>>>>>> (repository.xml, OBJ.properties below)
>>>>>>>>
>>>>>>>> repository.xml
>>>>>>>> <jdbc-connection-descriptor
>>>>>>>> jcd-alias="default"
>>>>>>>> default-connection="true"
>>>>>>>> platform="PostgreSQL"
>>>>>>>> jdbc-level="3.0"
>>>>>>>> jndi-datasource-name="java:comp/env/jdbc/mff/mffweb"
>>>>>>>> eager-release="false"
>>>>>>>> batch-mode="false"
>>>>>>>> useAutoCommit="1"
>>>>>>>> ignoreAutoCommitExceptions="false" > <object-cache
>>>>>>>> class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
>>>>>>>> <attribute attribute-name="cacheExcludes"
>>>>>>>> attribute-value=""/>
>>>>>>>> <attribute attribute-name="timeout" attribute-value="900"/>
>>>>>>>> <attribute attribute-name="autoSync"
>>>>>>>> attribute-value="true"/>
>>>>>>>> <attribute attribute-name="cachingKeyType"
>>>>>>>> attribute-value="0"/>
>>>>>>>> </object-cache>
>>>>>>>> <sequence-manager
>>>>>>>> className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl">
>>>>>>>>
>>>>>>>> </sequence-manager>
>>>>>>>> </jdbc-connection-descriptor >
>>>>>>>>
>>>>>>>> OBJ.properties
>>>>>>>> repositoryFile=repository.xml
>>>>>>>> useSerializedRepository=false
>>>>>>>> serializedRepositoryPath=.
>>>>>>>> PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
>>>>>>>>
>>>>>>>> PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
>>>>>>>>
>>>>>>>> maxActive=256
>>>>>>>> maxIdle=-1
>>>>>>>> maxWait=2000
>>>>>>>> timeBetweenEvictionRunsMillis=-1
>>>>>>>> minEvictableIdleTimeMillis=1000000
>>>>>>>> whenExhaustedAction=0
>>>>>>>> ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
>>>>>>>>
>>>>>>>> ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
>>>>>>>>
>>>>>>>> SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
>>>>>>>>
>>>>>>>> IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
>>>>>>>>
>>>>>>>> ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
>>>>>>>>
>>>>>>>> SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
>>>>>>>> CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
>>>>>>>>
>>>>>>>> StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
>>>>>>>>
>>>>>>>> JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
>>>>>>>> RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
>>>>>>>>
>>>>>>>> descriptorBasedCaches=false
>>>>>>>> LockManagerClass=org.apache.ojb.broker.locking.LockManagerInMemoryImpl
>>>>>>>>
>>>>>>>> LockTimeout=60000
>>>>>>>> OqlCollectionClass=org.apache.ojb.broker.util.collections.ManageableArrayList
>>>>>>>>
>>>>>>>> SqlInLimit=200
>>>>>>>> ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
>>>>>>>> OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
>>>>>>>> cascadingDeleteOneToOne=false
>>>>>>>> cascadingDeleteOneToN=false
>>>>>>>> cascadingDeleteMToN=false
>>>>>>>> ImplicitLocking=true
>>>>>>>> LockAssociations=WRITE
>>>>>>>> DListClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>> DArrayClass=org.apache.ojb.odmg.collections.DListImpl
>>>>>>>> DMapClass=org.apache.ojb.odmg.collections.DMapImpl
>>>>>>>> DBagClass=org.apache.ojb.odmg.collections.DBagImpl
>>>>>>>> DSetClass=org.apache.ojb.odmg.collections.DSetImpl
>>>>>>>> PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew
>>>>>>>>
>>>>>>>> JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org