-
Von: user@geronimo.apache.org
Gesendet: 25.04.07 17:44:44
An: user@geronimo.apache.org
Betreff: Re: OutOfMemoryException while redeploying WAR
On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote:
It's related to the way Sun's JVM handles class data and internalized string
On Apr 26, 2007, at 5:43 AM, Jochen Zink wrote:
Hello,
thanks for the answers (a lot of :) ). Yes it is en PermSpace Error
and if it is a problem with the JavaVM... I have to life with that.
It is only for developing an application. In production mode, there
is no need for a redeploy.
Hello,
I'm using Geronimo 1.1.1 and have a problem.
I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo
and after modifiying the sources I redploy the application WAR. That works
fine. But after a while, I get OutOfMemory Exceptions while redeploying. After
That has to do with the PermSize. It is the classloader's memory.
Set -XX:MaxPermSize=256M at startup.
--
Dario
Jochen Zink escreveu:
Hello,
I'm using Geronimo 1.1.1 and have a problem.
I'm developing a little JSF-Webapplication. First, I deploy the WAR to geronimo
and after modifiying
in error please notify
the system manager.
*
Dario Andrade [EMAIL PROTECTED]
04/25/2007 11:31 AM
Please respond to
user@geronimo.apache.org
To
user@geronimo.apache.org
cc
Subject
Re: OutOfMemoryException while redeploying WAR
On Apr 25, 2007, at 10:31 AM, Dario Andrade wrote:
That has to do with the PermSize. It is the classloader's memory.
Set -XX:MaxPermSize=256M at startup.
--
Dario
Jochen Zink escreveu:
Hello,
I'm using Geronimo 1.1.1 and have a problem.
I'm developing a little JSF-Webapplication. First,
On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote:
It's related to the way Sun's JVM handles class data and
internalized string. They make the assumption that you'd never want
that information flushed from the VM, so they put that chunk of
memory out of the reach of the garbage
to
user@geronimo.apache.org
To
user@geronimo.apache.org
cc
Subject
Re: OutOfMemoryException while redeploying WAR
On Apr 25, 2007, at 10:37 AM, [EMAIL PROTECTED] wrote:
It's related to the way Sun's JVM handles class data and internalized
string. They make the assumption that you'd never
Maybe you are referring to this issue in tomcat:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42172
If so then that classloader leak was attributed to how log4j was used
by the application.
Best wishes,
Paul
On Apr 25, 2007, at 11:19 AM, [EMAIL PROTECTED] wrote:
You're correct. But
