Re: Tomcat 5, JNDI, Perm Gen Memory leak

[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

[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