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
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 collector (i.e. permanent generation). Unfortunately, when
you
Does your EAR have a simple application.xml ? I solved a similar
problem by putting an application.xml
Cheers
Prasad
On 4/24/07, Jim Barrows [EMAIL PROTECTED] wrote:
I found all of the web pages pointing out what to do when this happens
in a WAR, and my WAR works just fine. However when I
On 4/25/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
Does your EAR have a simple application.xml ? I solved a similar
problem by putting an application.xml
Yes it does.
And no matter where I put the filter classes, I get the same problem.
Or if I just get rid of all the plans, that doesn't
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
You're correct. But there's been a lot of discussion surrounding this
issue in the Tomcat forums. Maybe it's because the ClassLoaders don't get
GC'ed correctly, but when Tomcat reloads an app, the class data seems to
never get GC'ed. The same issue was found with Jetty, so it seems to be a
VM
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
On Apr 25, 2007, at 8:14 AM, ananner wrote:
I also have a requirement to limit a certain MDB to a maximum of one
instance, but I am a bit confused as to your response. Are you
saying that
I should put a pool size limit on the outbound-resourceadapter which
defines the Connection Factory
If I have a Geronimo project that declares some dependencies like this:
dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version1.2.0-SNAPSHOT/version
typejar/type
/dependency
If geronimo supports JSP 2.1/Servlet 2.5 shouldn't this ${test.name} show
the proper value, right now it is showing blank instead of the name:
titleTitle? ${test.name}/title
12 matches
Mail list logo
