Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (herse.apache.org: local policy)
From: "Robin Rigby" <robin@gondolier.org.uk>
To: <users@cocoon.apache.org>
References: <4EB90BCB-5DD1-4442-9DA1-7285070B38F2@winnall.ch>
 <46A10707.7030900@agssa.net>
 <8847999A-E5E5-4B46-9C05-19A7EFBA9F7A@winnall.ch>
 <46A215CC.5060203@hipkiss.org>
 <36D0BA11-94B1-47FD-8941-E4AC66356B53@winnall.ch>
Subject: RE: PermGen space problem with Cocoon on Tomcat
Date: Sun, 22 Jul 2007 00:45:53 +0100
Message-ID: <002201c7cbf1$5a0d0cb0$306fa8c0@philosophy.pchl.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <36D0BA11-94B1-47FD-8941-E4AC66356B53@winnall.ch>
Thread-Index: AcfL7HiiNHwXbUOIQ7qlSTXZkan1KQAASL/Q

I had a similar thing a month or two ago.

I spent a lot of time looking in vain for a classloader leak.  It turned =
out
Cocoon needs more memory (on my system) than the Tomcat default.

Have you tried making more memory available to Tomcat?  I added memory
options to the script that launches Tomcat.  Something like

     -Xms256m \
     -Xmx512m \
     -XX:PermSize=3D64m \
     -XX:MaxPermSize=3D256m \
	etc =20

Problem gone.  I don't think there is a classloader leak (on my machine,
anyway).

I wrote a little script to log the permgen statistics as Tomcat starts =
up. =20

hth
=20
Robin
=20

-----Original Message-----
From: Stephen Winnall [mailto:steve@winnall.ch]=20
Sent: 21 July 2007 23:55
To: users@cocoon.apache.org
Subject: Re: PermGen space problem with Cocoon on Tomcat

I don't know how much memory the machine has. I have read various =20
articles on the net which have suggested increasing the memory =20
available to Tomcat's JVM (part of what Christoph suggested), but the =20
consensus seems to be that this merely defers the problem rather than =20
solving it. Memory leaks chew up memory until there is none left: =20
it's just a matter of how long it takes!

At the moment I'm concentrating on the JDBC hypothesis. If the =20
problem comes round again after that, there are two further =20
possibilities:

1) references (pointers) from outside the application to classes =20
within the application (non-JDBC)
2) memory size

I'm planning on taking them in that order. Although my instinct says =20
"fix the basic problem", if I only have to restart Tomcat say every =20
two weeks I may go with that if the solution proves too elusive.

Steve

On 21 Jul 2007, at 16:18, Jonathan Hipkiss wrote:

> Do you know how much memory the machine has?  We were getting this =20
> on a Solaris 10 server with 1gb of Ram which we doubled and the =20
> problem went away.
>
> Jonathan
>
> Stephen Winnall wrote:
>> Hi Antonio, Christoph
>>
>> I'm using Cocoon 2.1.9 on Tomcat 5.5.23 with Sun's Java 1.5.0_11-=20
>> b03 on Linux 2.6.18-4-amd64 (not sure which distro: it's at my =20
>> provider's site).
>>
>> Christoph's suggestions tally with things I've discovered on the =20
>> net in the last couple of hours. I'll run them past my provider.
>>
>> Another possibility seems to be JDBC: if the jar file is under WEB-=20
>> INF/lib the garbage collector cannot release resources held by the =20
>> database. Guess where my postgresql.jar is...
>>
>> Part of my problem is that I develop under Mac OS X and just =20
>> restart Tomcat when things go wrong in my development environment: =20
>> deploying to a completely different platform is forcing me to be =20
>> more rigorous.
>>
>> Steve
>>
>>
>> On 20 Jul 2007, at 21:03, Antonio Gallardo wrote:
>>
>>> Hi Stephen, would you provide more info?
>>>
>>> Java version, cocoon version, tomcat version, OS, etc?
>>>
>>> Best Regards,
>>>
>>> Antonio Gallardo.
>>>
>>> Stephen Winnall escribi=F3:
>>>> I'm trying to deploy my Cocoon application in Tomcat and am =20
>>>> getting the following error:
>>>>
>>>>     java.lang.OutOfMemoryError: PermGen space
>>>>
>>>> Wisdom on the net has it that this happens as a result of large =20
>>>> memory leaks: if classes used in a servlet are referenced from =20
>>>> outside the servlet, the garbage collector cannot recycle them =20
>>>> when the application is undeployed; redeploying the application =20
>>>> results in the classes being loaded a further time, and so on =20
>>>> until memory runs out. I have looked in the Cocoon mailing lists =20
>>>> for other occurrences of this problem, but I've found nothing, =20
>>>> so I assume the problem is in one of the classes I wrote to =20
>>>> extend my application.
>>>>
>>>> Does anyone have experience with tracking down this sort of =20
>>>> problem in Cocoon apps?
>>>>
>>>> Steve
>>>>
>>>>
>>>> ------------------------------------------------------------------- =

>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>> -------------------------------------------------------------------- =

>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org