subject:"Re\: OutOfMemoryError"

Mark (Thomas), Román, Guido, and Mark (Eggers)

Thank you all for your suggestions, assistance, and patience.

With your help and encouragement I learned how to perform heap dumps using Java 
VisualVM, analyze them using Eclipse Memory Analyzer, and follow instructions.  
;-)

The OutOfMemoryError in Tomcat Manager was caused by a memory leak when Log4J 
did not terminate properly.  This was due to my mistake of neglecting to set up 
the necessary Log4J shutdown procedures.

Adding Log4jServletContextListener and log4jServletFilter to my app's web.xml 
solved the problem.  The Find Leaks button on the Tomcat Manager page confirmed.

I apologize for taking your time and bandwidth on such a newbie mistake.

Thanks again for your help.  :-)

--
Cris Berneburg
CACI Lead Software Engineer

-Original Message-
From: Berneburg, Cris [mailto:cberneb...@caci.com] 
Sent: Thursday, July 14, 2016 2:27 PM
To: Tomcat Users List
Subject: OutOfMemoryError: PermGen space

> Hi Folks
>
> I got this error from the Tomcat Web Application Manager after having
> stopped and started one of the applications multiple times.  (This was
> after repeatedly deploying the application manually to attempt to find
> a bug that I could not reproduce in my IDE.)  Once the error occurred,
> the server was extremely sluggish to respond even to remote desktop
> mouse and keyboard events.

[SNIP]

> Here's the error:
>
> FAIL - Application at context path /someapp could not be started
> FAIL - Encountered exception java.lang.OutOfMemoryError: PermGen space
>
> Is this likely due to a memory leak in my application?

[SNIP]

> OS: Win Server 2012 R2
> Java: 1.6.0_24  (oops, need to upgrade that now)
> Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

Mark (Eggers) and Mark (Thomas)

BLUF:  Memory leak found and fixed.  I did not set up the necessary Log4J 
shutdown procedures.  Please see below.

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID]
Sent: Thursday, July 21, 2016 8:32 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> > From the log4j2 web site:
> > 
> > https://logging.apache.org/log4j/2.x/manual/webapp.html

[SNIP]

> > If you are using Log4j in a Servlet 2.5 web application, or if you 
> > have disabled auto-initialization with the 
> > isLog4jAutoInitializationDisabled context parameter, you must 
> > configure the Log4jServletContextListener and Log4jServletFilter in 
> > the deployment descriptor or programmatically.
>
> *** I did not do that at all.  Is it the context listener's responsibility
> for shutting down properly?  Why the filter is needed?  Guess I'll set them
> up and see if that makes a diff.


That fixed it.  Adding Log4jServletContextListener and log4jServletFilter to my 
web.xml solves the problem.  The Find Leaks button on the Tomcat Manager page 
confirms.

Chalk it up to a newbie error.

Thanks for your help and patience.  :-)

--
Cris Berneburg
CACI Lead Software Engineer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

Mark (Eggers) and Mark (Thomas)

BLUF:  I might not have set up the necessary Log4J shutdown procedures.  Please 
(especially) see my responses flagged by ***.

-Original Message-
From: Mark Eggers [mailto:its_toas...@yahoo.com.INVALID] 
Sent: Thursday, July 21, 2016 8:32 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> Mark and Cris,
> 
> On 7/21/2016 12:47 PM, Mark Thomas wrote:
> > On 21/07/2016 18:17, Berneburg, Cris wrote:
> >> From: Mark Thomas [mailto:ma...@apache.org]
> > 
> > 
> > 
> >> 
> >> Used the Java Visual VM to pull a heap dump after the app restart and 
> >> GC.  Used Eclipse Memory Analyzer to analyze the heap dumps.
> >> Found the WebappClassLoader with started == false and used Path to GC 
> >> roots:
> >> 
> >> 
> >> org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ...
> >> com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> >> 
> [SNIP]
> > 
> >> I don't see anything pointing back to our code.  With no previous 
> >> experience with heap analysis on my part, it looks to me to be due to 
> >> Log4J2.
> > 
> > Agreed.
> > 
> [SNIP]
> > 
> >> Not sure what else I can do.  Report it to the Log4J2 dev group 
> >> perhaps?
> > 
> > Ask on their users' list. It may be that when you use log4j2 in a 
> > webapp there is some clean-up method you need to call from a 
> > ServletContextListener.


OK, I'll follow up with that next-next.


> From the log4j2 web site:
> 
> https://logging.apache.org/log4j/2.x/manual/webapp.html


Thanks for pointing that out.  I'm looking through it again now:


> you'll need to add the log4j-web module to your deployment [...]
>
> To avoid problems the Log4j shutdown hook will automatically be
> disabled when the log4j-web jar is included. 


Hmm...  Log4j-web-2.3.jar is included in our apps lib folder.  I wonder if 
there is a shutdown procedure I am missing then.


> If you are using Log4j in a Servlet 2.5 web application, or if
> you have disabled auto-initialization with the
> isLog4jAutoInitializationDisabled context parameter, you must
> configure the Log4jServletContextListener and Log4jServletFilter
> in the deployment descriptor or programmatically.


*** I did not do that at all.  Is it the context listener's responsibility for 
shutting down properly?  Why the filter is needed?  Guess I'll set them up and 
see if that makes a diff.


> Asynchronous Requests and Threads
> [SNIP]
> Note that you must call clearLoggerContext once your thread is
> finished processing. Failing to do so will result in memory leaks.


*** Wait a minute.  Maybe I don't understand how servlet threads work in 
Tomcat.  We don't launch any separate threads, but do override doPost and doGet 
in our servlets.  Is that synchronous or asynchronous?  Do we still have to 
call webLifeCycle.clearLoggerContext?


> In servlet spec 3.0 and greater, there appears to be annotation
> that gets everything running.
> 
> In servlet spec 2.5, you'll have to add a bunch of stuff to
> your web.xml.
>
> The reference above gives a more detailed explanation and an
> example for the 2.5 web.xml.


Since we still use Tomcat 6, we used a 2.5 servlet spec config.  All the Log4J 
config info is in log4j2.xml.


> I am just starting to get things migrated to log4j2,
> so I'll know how it goes shortly.


Please do!

--
Cris Berneburg
CACI Lead Software Engineer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

Guido

Thanks for following up with me:

-Original Message-
From: Jäkel, Guido [mailto:g.jae...@dnb.de] 
Sent: Friday, July 22, 2016 4:31 AM
To: Berneburg, Cris
Subject: RE: OutOfMemoryError: PermGen space

> >-Original Message-
> >From: Berneburg, Cris [mailto:cberneb...@caci.com]
> >Sent: Thursday, July 21, 2016 6:18 PM
> >To: Tomcat Users List
> >Subject: RE: OutOfMemoryError: PermGen space
> >
> >Mark
> >
> >Thanks again for taking the time to assist with the OutOfMemoryError.  
> >BLUF, it looks like Log4J2 is the culprit.  Will you please check my work 
> >below to see if I have interpreted correctly?
> 
> Dear Chris,
> 
> Is the Log4J-JAR located at the "right place" with respect
> to the classloader path, i.e. inside the webapps lib directory?


Yup, the Log4J jars are in the webapp's lib folder and not in Tomcat's lib 
folder.  I just triple-checked.  ;-)


> Is Log4J2 is just used for your application or for Tomcat logging, too? 


Just for my app and not Tomcat.

--
Cris Berneburg
CACI Lead Software Engineer

RE: OutOfMemoryError: PermGen space

Mark

BLUF:  Thanks for your explanations and assistance.  I plan to follow up with 
the Log4J2 group.  My simple responses below.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, July 21, 2016 3:47 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 21/07/2016 18:17, Berneburg, Cris wrote:
> > From: Mark Thomas [mailto:ma...@apache.org]
> 
> 
> 
> > 
> > Used the Java Visual VM to pull a heap dump after the app
> > restart and GC.  Used Eclipse Memory Analyzer to analyze
> > the heap dumps.  Found the WebappClassLoader with started
> > == false and used Path to GC roots:
> > 
> >  org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ... 
> > com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> > 
> >  org.apache.logging.log4j.core.jmx.LoggerContextAdmin ... 
> > com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> > 
> >  org.apache.logging.log4j.core.jmx.StatusLoggerAdmin ... 
> > com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> 
> The three above look problematic.
> 
> > referent java.util.WeakHashMap$Entry ... java.lang.reflect.Proxy
> 
> That should disappear once the problematic entries have been fixed
> 
> >  $Proxy3 ... java.lang.reflect.Proxy
> 
> That looks to be related to the previous GC root and should also
> disappear once the problematic entries are fixed.
> 
> > referent java.util.WeakHashMap$Entry ... 
> > org.apache.juli.ClassLoaderLogManager
> > ... (many java.util.logging.*)
> 
> Again, those will disappear once the issues are fixed. They are Tomcat's
> internal logging


Thanks for explaining those to me.


> > I don't see anything pointing back to our code.  With 
> > no previous experience with heap analysis on my part,
> > it looks to me to be due to Log4J2.
> 
> Agreed.


Great!


> >  Changing the args for the call to LogManager.getLogger from
> Class clazz to none made no appreciable difference.
> 
> I wouldn't expect that to make any difference.
> 
> >  (Did I somehow set up Log4J2 incorrectly to get it to misbehave?)
> 
> I don't think so.


I wanted to make sure that holding onto class references wasn't a problem.  
Later I even replaced all the static vars with non-static locals as an 
experiment just in case ;-) and it made no diff.  Yeah, I know, you previously 
said that removing a static would not help, but I had to try anyway because I 
don't fully understand it all.  If there's a chance I did something goofy to 
cause the issue, I want to eliminate that possibility.


> >  Not sure what else I can do.  Report it to the Log4J2 dev group perhaps?
> 
> Ask on their users' list. It may be that when you use log4j2 in a webapp
> there is some clean-up method you need to call from a
> ServletContextListener.


OK, I'll do that next after following up with the other folks in this group.


> >> One thing worth noting. Yourkit offers two types of heap dumps.
> >> You don't want YourKit's own. There is a JVM bug that prevents
> >> some GC roots from being shown in that format and if your leak
> >> traces back to one of those you can end up scratching your head
> >> for days.
> >>
> >> Mark
> > 
> > 
> > Is there a likely chance that the bug interfered with my usage of
> > Java Visual VM and Eclipse Memory Analyzer and thus prevented me
> > from determining the real problem source?
> 
> No. The bug just hides GC roots. If the only GC roots you see are for
> weak references then you might have hit this bug.


Ah good, that's a relief and good to know.

Thanks!

--
Cris Berneburg
CACI Lead Software Engineer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

2016-07-22 Thread Jäkel , Guido

>-Original Message-
>From: Berneburg, Cris J. - US [mailto:cberneb...@caci.com]
>Sent: Thursday, July 21, 2016 6:18 PM
>To: Tomcat Users List
>Subject: RE: OutOfMemoryError: PermGen space
>
>Mark
>
>Thanks again for taking the time to assist with the OutOfMemoryError.  BLUF, 
>it looks like Log4J2 is the culprit.  Will you
>please check my work below to see if I have interpreted correctly?

Dear Chris,

Is the Log4J-JAR located at the "right place" with respect to the classloader 
path, i.e. inside the webapps lib directory? Is Log4J2 is just used for your 
application or for Tomcat logging, too? 

Guido

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space

2016-07-21 Thread Mark Eggers

Mark and Cris,

On 7/21/2016 12:47 PM, Mark Thomas wrote:
> On 21/07/2016 18:17, Berneburg, Cris J. - US wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
> 
> 
> 
>> Using the Find Leaks button on the Tomcat Manager page on old app
>> versions to trigger full garbage collection revealed that the
>> memory leak started to happen in the release when Log4J2 was added
>> to the app.  It did not start happening in the prior release when
>> Mybatis was added.
> 
> It isn't essential but that is a good idea to do that to give you an 
> idea of what you are looking for.
> 
>>> This should help: http://markmail.org/message/fcbvwapt6afyndxn
>> 
>>> 1. Find an app that you can't reload without OOME 2. Get a
>>> profiler [...] 3. Reload you app once 4. Use the profiler to look
>>> for instances of WebappClassLoader 5. Look for the one with the
>>> started attribute == false 6. Trace the GC roots for this
>>> instance
>> 
>> 
>> Used the Java Visual VM to pull a heap dump after the app restart
>> and GC.  Used Eclipse Memory Analyzer to analyze the heap dumps.
>> Found the WebappClassLoader with started == false and used Path to
>> GC roots:
>> 
>> 
>> org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ...
>> com.sun.jmx.mbeanserver.StandardMBeanIntrospector
>> 
>>  org.apache.logging.log4j.core.jmx.LoggerContextAdmin
>> ... com.sun.jmx.mbeanserver.StandardMBeanIntrospector
>> 
>>  org.apache.logging.log4j.core.jmx.StatusLoggerAdmin
>> ... com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> 
> The three above look problematic.
> 
>> referent java.util.WeakHashMap$Entry ... java.lang.reflect.Proxy
> 
> That should disappear once the problematic entries have been fixed
> 
>>  $Proxy3 ... java.lang.reflect.Proxy
> 
> That looks to be related to the previous GC root and should also 
> disappear once the problematic entries are fixed.
> 
>> referent java.util.WeakHashMap$Entry ...
>> org.apache.juli.ClassLoaderLogManager ... (many
>> java.util.logging.*)
> 
> Again, those will disappear once the issues are fixed. They are
> Tomcat's internal logging
> 
>> I don't see anything pointing back to our code.  With no previous
>> experience with heap analysis on my part, it looks to me to be due
>> to Log4J2.
> 
> Agreed.
> 
>> Changing the args for the call to LogManager.getLogger from
>> Class clazz to none made no appreciable difference.
> 
> I wouldn't expect that to make any difference.
> 
>> (Did I somehow set up Log4J2 incorrectly to get it to misbehave?)
> 
> I don't think so.
> 
>> Not sure what else I can do.  Report it to the Log4J2 dev group
>> perhaps?
> 
> Ask on their users' list. It may be that when you use log4j2 in a
> webapp there is some clean-up method you need to call from a 
> ServletContextListener.
> 

From the log4j2 web site:

https://logging.apache.org/log4j/2.x/manual/webapp.html

In servlet spec 3.0 and greater, there appears to be annotation that
gets everything running.

In servlet spec 2.5, you'll have to add a bunch of stuff to your web.xml.

The reference above gives a more detailed explanation and an example for
the 2.5 web.xml.

I am just starting to get things migrated to log4j2, so I'll know how it
goes shortly.

Sigh . . . days late, and dollars short.

>>> One thing worth noting. Yourkit offers two types of heap dumps. 
>>> You don't want YourKit's own. There is a JVM bug that prevents 
>>> some GC roots from being shown in that format and if your leak 
>>> traces back to one of those you can end up scratching your head 
>>> for days.
>>> 
>>> Mark
>> 
>> 
>> Is there a likely chance that the bug interfered with my usage of
>> Java Visual VM and Eclipse Memory Analyzer and thus prevented me
>> from determining the real problem source?
> 
> No. The bug just hides GC roots. If the only GC roots you see are
> for weak references then you might have hit this bug.
> 
> Mark

. . . just my two cents
/mde/



signature.asc
Description: OpenPGP digital signature

Re: OutOfMemoryError: PermGen space

2016-07-21 Thread Mark Thomas

On 21/07/2016 18:17, Berneburg, Cris J. - US wrote:
> From: Mark Thomas [mailto:ma...@apache.org]



> Using the Find Leaks button on the Tomcat Manager page on old app versions to 
> trigger full garbage collection revealed that the memory leak started to 
> happen in the release when Log4J2 was added to the app.  It did not start 
> happening in the prior release when Mybatis was added.

It isn't essential but that is a good idea to do that to give you an
idea of what you are looking for.

>> This should help:
>> http://markmail.org/message/fcbvwapt6afyndxn
> 
>> 1. Find an app that you can't reload without OOME
>> 2. Get a profiler [...]
>> 3. Reload you app once
>> 4. Use the profiler to look for instances of WebappClassLoader
>> 5. Look for the one with the started attribute == false
>> 6. Trace the GC roots for this instance
> 
> 
> Used the Java Visual VM to pull a heap dump after the app restart and GC.  
> Used Eclipse Memory Analyzer to analyze the heap dumps.  Found the 
> WebappClassLoader with started == false and used Path to GC roots:
> 
>  org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ... 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> 
>  org.apache.logging.log4j.core.jmx.LoggerContextAdmin ... 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector
> 
>  org.apache.logging.log4j.core.jmx.StatusLoggerAdmin ... 
> com.sun.jmx.mbeanserver.StandardMBeanIntrospector

The three above look problematic.

> referent java.util.WeakHashMap$Entry ... java.lang.reflect.Proxy

That should disappear once the problematic entries have been fixed

>  $Proxy3 ... java.lang.reflect.Proxy

That looks to be related to the previous GC root and should also
disappear once the problematic entries are fixed.

> referent java.util.WeakHashMap$Entry ... 
> org.apache.juli.ClassLoaderLogManager ... (many java.util.logging.*)

Again, those will disappear once the issues are fixed. They are Tomcat's
internal logging

> I don't see anything pointing back to our code.  With no previous experience 
> with heap analysis on my part, it looks to me to be due to Log4J2.

Agreed.

>  Changing the args for the call to LogManager.getLogger from Class clazz 
> to none made no appreciable difference.

I wouldn't expect that to make any difference.

>  (Did I somehow set up Log4J2 incorrectly to get it to misbehave?)

I don't think so.

>  Not sure what else I can do.  Report it to the Log4J2 dev group perhaps?

Ask on their users' list. It may be that when you use log4j2 in a webapp
there is some clean-up method you need to call from a
ServletContextListener.

>> One thing worth noting. Yourkit offers two types of heap dumps.
>> You don't want YourKit's own. There is a JVM bug that prevents
>> some GC roots from being shown in that format and if your leak
>> traces back to one of those you can end up scratching your head
>> for days.
>>
>> Mark
> 
> 
> Is there a likely chance that the bug interfered with my usage of Java Visual 
> VM and Eclipse Memory Analyzer and thus prevented me from determining the 
> real problem source?

No. The bug just hides GC roots. If the only GC roots you see are for
weak references then you might have hit this bug.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

2016-07-21 Thread Berneburg, Cris J. - US

Mark

Thanks again for taking the time to assist with the OutOfMemoryError.  BLUF, it 
looks like Log4J2 is the culprit.  Will you please check my work below to see 
if I have interpreted correctly?

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, July 20, 2016 12:17 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 20/07/2016 17:31, Berneburg, Cris wrote:
> > Mark
> > 
> > Thanks again for taking the time to educate me and answer my 
> > questions.  My lengthy replies below.  To summarize, our app does not 
> > seem to commit any egregious memory leak offenses, from what I can 
> > tell so far.  I plan to heap dump an older version of the app that 
> > does not use third-party libraries for comparison purposes.

Using the Find Leaks button on the Tomcat Manager page on old app versions to 
trigger full garbage collection revealed that the memory leak started to happen 
in the release when Log4J2 was added to the app.  It did not start happening in 
the prior release when Mybatis was added.

> This should help:
> http://markmail.org/message/fcbvwapt6afyndxn

> 1. Find an app that you can't reload without OOME
> 2. Get a profiler [...]
> 3. Reload you app once
> 4. Use the profiler to look for instances of WebappClassLoader
> 5. Look for the one with the started attribute == false
> 6. Trace the GC roots for this instance

Used the Java Visual VM to pull a heap dump after the app restart and GC.  Used 
Eclipse Memory Analyzer to analyze the heap dumps.  Found the WebappClassLoader 
with started == false and used Path to GC roots:

 org.apache.logging.log4j.core.jmx.LoggerContextAdminMBean ... 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector

 org.apache.logging.log4j.core.jmx.LoggerContextAdmin ... 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector

 org.apache.logging.log4j.core.jmx.StatusLoggerAdmin ... 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector

referent java.util.WeakHashMap$Entry ... java.lang.reflect.Proxy

 $Proxy3 ... java.lang.reflect.Proxy

referent java.util.WeakHashMap$Entry ... org.apache.juli.ClassLoaderLogManager 
... (many java.util.logging.*)

I don't see anything pointing back to our code.  With no previous experience 
with heap analysis on my part, it looks to me to be due to Log4J2.  Changing 
the args for the call to LogManager.getLogger from Class clazz to none made 
no appreciable difference.  (Did I somehow set up Log4J2 incorrectly to get it 
to misbehave?)  Not sure what else I can do.  Report it to the Log4J2 dev group 
perhaps?

> One thing worth noting. Yourkit offers two types of heap dumps.
> You don't want YourKit's own. There is a JVM bug that prevents
> some GC roots from being shown in that format and if your leak
> traces back to one of those you can end up scratching your head
> for days.
> 
> Mark

Is there a likely chance that the bug interfered with my usage of Java Visual 
VM and Eclipse Memory Analyzer and thus prevented me from determining the real 
problem source?

--
Cris Berneburg, Lead Software Engineer, CACI

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space

2016-07-20 Thread Mark Thomas

On 20/07/2016 17:31, Berneburg, Cris J. - US wrote:
> Mark
> 
> Thanks again for taking the time to educate me and answer my
> questions.  My lengthy replies below.  To summarize, our app does not
> seem to commit any egregious memory leak offenses, from what I can
> tell so far.  I plan to heap dump an older version of the app that
> does not use third-party libraries for comparison purposes.

This should help:
http://markmail.org/message/fcbvwapt6afyndxn

One thing worth noting. Yourkit offers two types of heap dumps. You
don't want YourKit's own. There is a JVM bug that prevents some GC roots
from being shown in that format and if your leak traces back to one of
those you can end up scratching your head for days.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

2016-07-20 Thread Berneburg, Cris J. - US

Mark

Thanks again for taking the time to educate me and answer my questions.  My 
lengthy replies below.  To summarize, our app does not seem to commit any 
egregious memory leak offenses, from what I can tell so far.  I plan to heap 
dump an older version of the app that does not use third-party libraries for 
comparison purposes.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, July 19, 2016 3:15 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 19/07/2016 17:19, Berneburg, Cris J. - US wrote:
> 
> 
> 
> >> This is probably a useful read:
> >> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks
> >> -60mins.pdf
> >>
> >> Despite the age, it is still very relevant today.
> > 
> > 
> > Thanks for reminding me about that document.  It does sound relevant.  
> > The document says,
> > 
> >> How memory leaks occur: Reference chains [...] Retaining a reference 
> >> to a single object from a web application pins every class loaded by 
> >> the web application in the Permanent Generation
> > 
> > Practically speaking, how is a reference retained?
> > 1. Is a module-level (member) variable in a Servlet an example?
> 
> No. Assuming the class that defines the Servlet is packaged with the
> web application (i.e. in a JAR in WEB-INF/lib or in WEB-INF/classes

All our servlets are classes in WEB-INF/classes.

> > 2. How about using ServletContext.setAttribute without an accompanying
> > removeAttribute?
> 
> No.
> 
> > 3. I see in one of my listeners some member (module-level) variables:
> > a private static for the logger and also a protected final String.
> > Is that a problem?
> 
> No.

Dang, I was hoping that would be it.  :-)

> > If you could provide a little more guidance about the details, I would
> > appreciate it.
> 
> Sure.
> 
> There are two categories of objects we are concerned about. Objects
> defined by classes that are provided by your web application (in
> WEB-INF/lib or WEB-INF/classes) and objects defined by classes that
> are provided by the container (Tomcat) or the JVM.
> 
> References from web application objects to web application objects
> are fine.
> 
> References from web application objects to container objects are fine.
> 
> References from container objects to web application objects are
> potentially a problem.
> 
> Additionally, references from container objects to the web application
> class loader are potentially a problem.

Hmm... I'm gonna need some time to absorb that.

> For example:
> 
> When you start a thread in a web application, the thread context
> class loader will be the web application class loader and the thread
> holds a reference to this. If the thread is not stopped when the web
> application is stopped there will be a reference held to the web
> application class loader which will cause a leak.

To my knowledge we are not explicitly starting any new threads.  Our app is 
pretty basic.

> If you add a logging framework to Tomcat's lib directory and then
> package a custom log formatter with your web application, the formatter
> will be registered with the logging framework and unless you unregister
> it when the application stops there will be reference from logging
> framework to custom formatter object to custom formatter class to web
> application class loader which will cause a leak.

We did not program a custom formatter with LOG4J2, just used a format parm in 
the config.  Also, LOG4J jar files were added the to the app WEB-INF/lib 
folder, not Tomcat's.

Sounds like there are a lot of potential sources for memory leaks.  I'm either 
going to have to keep digging deeper using a heap dump tool or simply punt 
without figuring it out.  Will a heap dump analyzer reveal what instances are 
in PermGen space and what has references to them?  Maybe I can follow up a 
chain of references to determine the source.

In the heap dump the largest collection of instances is java.lang.String.  
Could concatenation by assignment be a problem?  Example, abc = abc + xzy.  
While we are guilty of that, performing a heap dump on a fresh, idle, unused 
app would not have called the offending code.  So that cannot be it.

The second and third largest groups of instances in the heap dump are char[] 
and java.util.HashMap$Entry.  They must be from a library or third-party class, 
since not one char or HashMap instance is declared in our entire application.

As an experiment, I may grab heap dumps from and restart an older version of 
the app that does not use Mybatis or Log4J to see how that affects the top 3 
class instances.  If the sizes are significantly smaller, then perhaps the 
leaks are fro

RE: OutOfMemoryError: PermGen space

2016-07-20 Thread Berneburg, Cris J. - US

Hi Guido

Thanks for taking the time to answer my questions and make suggestions.  My 
replies below.

-Original Message-
From: Jäkel, Guido [mailto:g.jae...@dnb.de] 
Sent: Tuesday, July 19, 2016 10:31 AM
To: 'Tomcat Users List'
Subject: RE: OutOfMemoryError: PermGen space

>> In Visual VM, under File, Compare Memory Snapshots, it does not see the 
>> snapshots I generated.  The snapshots appear to be extension *.apps, 
>> but the compare function looks for files with extension *.nps.  I don't
>> know how to get the compare function to work.
>> 
>> Not sure where to go from here.  Got any suggestions?
> 
> You may pull heap dumps and use the Eclipse Memory Analyzer Toolkit (aka
> MAT)  (http://www.eclipse.org/mat/) to discover stale objects danging on
> the webapps classloader. The tool may be used stand-alone (via an included
> Eclipse RCP) or as an Eclipse Plugin.

Thanks for the suggestion.  I've never used that tool before.  Will it read the 
heap dumps generated by Visual VM?  I'll either try MAT or see if IntelliJ Idea 
has one, since Idea is my IDE.

[SNIP]

> If possible in any way, please upgrade to (Oracle) Java 1.8, because to
> my experience, there seems even notable fixes inside the Java core
> libraries. And enable the newest "G1" garabarge collector, too. Without
> changing any line in our apps, the JVM heap usage was notable smaller
> and smoother. Because of migrating with the [...] VM, the PermGen-Heap
> have been replaced by the Metaspace-Heap. Some parts of allocation now
> in the main heap and is reclaimable, some other remain. But technical,
> the Metaspace heap is now handled as all others, therefore it has no
> real separate size. You may set (and should) a limit, but per default
> it's unlimitied within the main heap.

I plan on upgrading to Java 1.8 soon but not quite yet, hoping to figure this 
out before doing so.  I don't want to change something that could potentially 
make the symptom go away but simply hide the underlying problem.

Thanks for reminding me about G1.  Is there any reason not to enable G1 garbage 
collection?  Also, Google says that there are potentially 3 ways of enabling it:

1. Customizing the Tomcat startup procedures to add the -XX:+UseG1GC option.  
This requires modifying the Tomcat startup every time you install Tomcat.

2. Setting the JAVA_TOOL_OPTIONS Java environment variable.  This makes G1 
default for all Java applications.

3. Setting the JAVA_OPTS environment variable that Tomcat might look for?  Not 
sure about this one.

> Greetings
> 
> Guido

--
Cris Berneburg, Lead Software Engineer, CACI

Re: OutOfMemoryError: PermGen space

2016-07-19 Thread Román Valoria

Cris:

You are looking at the wrong memory object. You need to focus on the
PermGen memory tab, not the Heap one.

That is, of course, if your memory error is indeed mentioning PermGen as in
the subject of this mail.

Again the PermGen holds the classes metadata definitions, so it should not
be impacted by how many times you call the classes or how much memory they
consume or how much data you are loading into memory.

I have never ran it with anything later than Java 6 and Tomcat 7, so I
cannot comment you your other errors.

Regards,

Roman.

On Tue, Jul 19, 2016 at 10:08 PM, Berneburg, Cris J. - US <
cberneb...@caci.com> wrote:

> Román
>
> Thanks for taking the time to reply and educate me.  :-)  Please see my
> ramblings below.
>
> -Original Message-
> From: Román Valoria [mailto:romanvalo...@gmail.com]
> Sent: Thursday, July 14, 2016 11:28 PM
> To: Tomcat Users List
> Subject: Re: OutOfMemoryError: PermGen space
>
> > Cris:
> >
> > Couple of things here.
> >
> > First, you can use in any Java 6 Update 45 and above the Java Visual VM,
> > to monitor in real time the memory utilization done by the Java virtual
> > machine. This will show you both the Help and Perm Gen memory graphs.
> > You can find this tool in the bin directory of any JDK.
>
>
> Thanks for suggesting that.  I have never used the Java Visual VM before.
> Upon trying it, I can't seem to get the tool to find Tomcat running, even
> when starting the tool with administrative privileges.  The only local
> application it sees is itself, VisualVM.  Tomcat is not visible to the tool
> running either as a Windows service nor by starting using startup.bat.
>
> Having never used the tool before I suspect I have missed something very
> basic.  Hmm... Google says I need to enable JMX on Tomcat and then add the
> JMX connection to Visual VM.  No dice, still can't see Tomcat.  Java bug
> #7009828 (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7009828)
> prevents Visual VM from connecting but says I can launch the tool with
> Java's temp directory matching Tomcat's temp dir (or something like that).
> That did it!  Now Visual VM can see Tomcat.
>
> I took a snapshot and heap dump, restarted my app 5x, then took another
> snapshot and heap dump.  The first dump is 25MB, and the second after all
> the restarts is 46MB.  The top 3 classes in both are java.lang.String,
> char[], java.util.HashMap$Entry.  How do I pinpoint where a potential
> problem is?
>
> In Visual VM, under File, Compare Memory Snapshots, it does not see the
> snapshots I generated.  The snapshots appear to be extension *.apps, but
> the compare function looks for files with extension *.nps.  I don't know
> how to get the compare function to work.
>
> Not sure where to go from here.  Got any suggestions?
>
>
> > Second, you can issue some Java parameters to actually enlarge the
> > PermGen memory allocation upon startup. Please refer to your java
> > version documentation on Oracle and lookup for the -XX parameters.
> >
> > You can start by enlarging your PermGen space and the monitor on the
> > Visual VM the behavior, if you consistently run out of memory, then
> > you may have a leak.
> >
> > Of course that you would be constrained by the fact of running a
> > 32-bit or 64-bit Tomcat / Java environment.
> >
> >
> > On Fri, Jul 15, 2016 at 2:26 AM, Berneburg, Cris J. - US <
> cberneb...@caci.com> wrote:
> >
> > > Hi Folks
> > >
> > > I got this error from the Tomcat Web Application Manager after having
> > > stopped and started one of the applications multiple times.  (This was
> > > after repeatedly deploying the application manually to attempt to find
> > > a bug that I could not reproduce in my IDE.)  Once the error occurred,
> > > the server was extremely sluggish to respond even to remote desktop
> > > mouse and keyboard events.
> > >
> > > FYI, I deploy the app by stopping it on the Tomcat web manager,
> > > deleting almost everything out of the app folder using file manager,
> > > copying the new files and folders in, then starting the app from the
> Tomcat manager.
> > >
> > > Here's the error:
> > >
> > > FAIL - Application at context path /someapp could not be started FAIL
> > > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> > >
> > > Is this likely due to a memory leak in my application?  Or does it
> > > have something to do with me doing so many repeated deployments?  Or
> > > perhaps simply from restarting the app so many times?  I might try an
> > > experiment to see how many times I can stop/start the app before the
> error next occurs.
> > >
> > > OS: Win Server 2012 R2
> > > Java: 1.6.0_24  (oops, need to upgrade that now)
> > > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> > >
> > > --
> > > Cris Berneburg, Lead Software Engineer, CACI
> > >
>
> --
> Cris Berneburg, Lead Software Engineer, CACI
>
>

Re: OutOfMemoryError: PermGen space

2016-07-19 Thread Mark Thomas

On 19/07/2016 17:19, Berneburg, Cris J. - US wrote:

>> This is probably a useful read:
>> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
>>
>> Despite the age, it is still very relevant today.
> 
> 
> Thanks for reminding me about that document.  It does sound relevant.  The 
> document says,
> 
>> How memory leaks occur: Reference chains
>> [...]
>> Retaining a reference to a single object from a web application
>> pins every class loaded by the web application in the Permanent
>> Generation
> 
> Practically speaking, how is a reference retained?
> 1. Is a module-level (member) variable in a Servlet an example?

No. Assuming the class that defines the Servlet is packaged with the web
application (i.e. in a JAR in WEB-INF/lib or in WEB-INF/classes

> 2. How about using ServletContext.setAttribute without an accompanying 
> removeAttribute?

No.

> 3. I see in one of my listeners some member (module-level) variables: a 
> private static for the logger and also a protected final String.  Is that a 
> problem?

No.

> If you could provide a little more guidance about the details, I would 
> appreciate it.

Sure.

There are two categories of objects we are concerned about. Objects
defined by classes that are provided by your web application (in
WEB-INF/lib or WEB-INF/classes) and objects defined by classes that are
provided by the container (Tomcat) or the JVM.

References from web application objects to web application objects are fine.

References from web application objects to container objects are fine.

References from container objects to web application objects are
potentially a problem.

Additionally, references from container objects to the web application
class loader are potentially a problem.

For example:

When you start a thread in a web application, the thread context class
loader will be the web application class loader and the thread holds a
reference to this. If the thread is not stopped when the web application
is stopped there will be a reference held to the web application class
loader which will cause a leak.

If you add a logging framework to Tomcat's lib directory and then
package a custom log formatter with your web application, the formatter
will be registered with the logging framework and unless you unregister
it when the application stops there will be reference from logging
framework to custom formatter object to custom formatter class to web
application class loader which will cause a leak.

HTH,

Mark

P.S. I'll be talking about this (hopefully - if my talk gets accepted)
at ApacheCon EU later this year.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

2016-07-19 Thread Berneburg, Cris J. - US

Mark

Thanks for taking the time to answer my questions.  Please see my response and 
questions below.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, July 14, 2016 2:58 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> On 14/07/2016 20:26, Berneburg, Cris wrote:
> 
> > Hi Folks
> > 
> > I got this error from the Tomcat Web Application Manager after having
> > stopped and started one of the applications multiple times.  (This was
> > after repeatedly deploying the application manually to attempt to find
> > a bug that I could not reproduce in my IDE.)  Once the error occurred,
> > the server was extremely sluggish to respond even to remote desktop
> > mouse and keyboard events.
> > 
> > [SNIP]
> > 
> > Here's the error:
> > 
> > FAIL - Application at context path /someapp could not be started FAIL 
> > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> > 
> > Is this likely due to a memory leak in my application?
> 
> Yes.
> 
> >  Or does it have something to do with me doing so many repeated deployments?
> 
> Also yes.
> 
> >  Or perhaps simply from restarting the app so many times?
> 
> Stop/start has the same effect as redeploy in this case.
> 
> >  I might try an experiment to see how many times I can stop/start the
> > app before the error next occurs.
> > 
> > OS: Win Server 2012 R2
> > Java: 1.6.0_24  (oops, need to upgrade that now)
> > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> 
> Indeed. Some upgrades are certainly in order. Not least because some of
> the potential sources of memory leaks are JVM bugs that are fixed in
> the lastest Java 8 releases.
> 
> This is probably a useful read:
> http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf
> 
> Despite the age, it is still very relevant today.


Thanks for reminding me about that document.  It does sound relevant.  The 
document says,

> How memory leaks occur: Reference chains
> [...]
> Retaining a reference to a single object from a web application
> pins every class loaded by the web application in the Permanent
> Generation

Practically speaking, how is a reference retained?
1. Is a module-level (member) variable in a Servlet an example?
2. How about using ServletContext.setAttribute without an accompanying 
removeAttribute?
3. I see in one of my listeners some member (module-level) variables: a private 
static for the logger and also a protected final String.  Is that a problem?

If you could provide a little more guidance about the details, I would 
appreciate it.

> Mark

--
Cris Berneburg, Lead Software Engineer, CACI


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError: PermGen space

2016-07-19 Thread Jäkel , Guido

>In Visual VM, under File, Compare Memory Snapshots, it does not see the 
>snapshots I generated.  The snapshots appear to
>be extension *.apps, but the compare function looks for files with extension 
>*.nps.  I don't know how to get the compare
>function to work.
>
>Not sure where to go from here.  Got any suggestions?

You may pull heap dumps and use the Eclipse Memory Analyzer Toolkit (aka MAT)  
(http://www.eclipse.org/mat/) to discover stale objects danging on the webapps 
classloader. The tool may be used stand-alone (via an included  Eclipse RCP) or 
as an Eclipse Plugin.


Greetings

Guido

RE: OutOfMemoryError: PermGen space

2016-07-19 Thread Berneburg, Cris J. - US

Román

Thanks for taking the time to reply and educate me.  :-)  Please see my 
ramblings below.

-Original Message-
From: Román Valoria [mailto:romanvalo...@gmail.com] 
Sent: Thursday, July 14, 2016 11:28 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError: PermGen space

> Cris:
> 
> Couple of things here.
> 
> First, you can use in any Java 6 Update 45 and above the Java Visual VM,
> to monitor in real time the memory utilization done by the Java virtual
> machine. This will show you both the Help and Perm Gen memory graphs.
> You can find this tool in the bin directory of any JDK.

Thanks for suggesting that.  I have never used the Java Visual VM before.  Upon 
trying it, I can't seem to get the tool to find Tomcat running, even when 
starting the tool with administrative privileges.  The only local application 
it sees is itself, VisualVM.  Tomcat is not visible to the tool running either 
as a Windows service nor by starting using startup.bat.

Having never used the tool before I suspect I have missed something very basic. 
 Hmm... Google says I need to enable JMX on Tomcat and then add the JMX 
connection to Visual VM.  No dice, still can't see Tomcat.  Java bug #7009828 
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7009828) prevents Visual 
VM from connecting but says I can launch the tool with Java's temp directory 
matching Tomcat's temp dir (or something like that).  That did it!  Now Visual 
VM can see Tomcat.

I took a snapshot and heap dump, restarted my app 5x, then took another 
snapshot and heap dump.  The first dump is 25MB, and the second after all the 
restarts is 46MB.  The top 3 classes in both are java.lang.String, char[], 
java.util.HashMap$Entry.  How do I pinpoint where a potential problem is?

In Visual VM, under File, Compare Memory Snapshots, it does not see the 
snapshots I generated.  The snapshots appear to be extension *.apps, but the 
compare function looks for files with extension *.nps.  I don't know how to get 
the compare function to work.

Not sure where to go from here.  Got any suggestions?

> Second, you can issue some Java parameters to actually enlarge the
> PermGen memory allocation upon startup. Please refer to your java
> version documentation on Oracle and lookup for the -XX parameters.
> 
> You can start by enlarging your PermGen space and the monitor on the
> Visual VM the behavior, if you consistently run out of memory, then
> you may have a leak.
>
> Of course that you would be constrained by the fact of running a
> 32-bit or 64-bit Tomcat / Java environment.
> 
> 
> On Fri, Jul 15, 2016 at 2:26 AM, Berneburg, Cris J. - US < 
> cberneb...@caci.com> wrote:
> 
> > Hi Folks
> >
> > I got this error from the Tomcat Web Application Manager after having 
> > stopped and started one of the applications multiple times.  (This was 
> > after repeatedly deploying the application manually to attempt to find 
> > a bug that I could not reproduce in my IDE.)  Once the error occurred, 
> > the server was extremely sluggish to respond even to remote desktop 
> > mouse and keyboard events.
> >
> > FYI, I deploy the app by stopping it on the Tomcat web manager, 
> > deleting almost everything out of the app folder using file manager, 
> > copying the new files and folders in, then starting the app from the Tomcat 
> > manager.
> >
> > Here's the error:
> >
> > FAIL - Application at context path /someapp could not be started FAIL 
> > - Encountered exception java.lang.OutOfMemoryError: PermGen space
> >
> > Is this likely due to a memory leak in my application?  Or does it 
> > have something to do with me doing so many repeated deployments?  Or 
> > perhaps simply from restarting the app so many times?  I might try an 
> > experiment to see how many times I can stop/start the app before the error 
> > next occurs.
> >
> > OS: Win Server 2012 R2
> > Java: 1.6.0_24  (oops, need to upgrade that now)
> > Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
> >
> > --
> > Cris Berneburg, Lead Software Engineer, CACI
> >

--
Cris Berneburg, Lead Software Engineer, CACI

Re: OutOfMemoryError: PermGen space

2016-07-14 Thread Román Valoria

Cris:

Couple of things here.

First, you can use in any Java 6 Update 45 and above the Java Visual VM, to
monitor in real time the memory utilization done by the Java virtual
machine. This will show you both the Help and Perm Gen memory graphs. You
can find this tool in the bin directory of any JDK.

Second, you can issue some Java parameters to actually enlarge the PermGen
memory allocation upon startup. Please refer to your java version
documentation on Oracle and lookup for the -XX parameters.

You can start by enlarging your PermGen space and the monitor on the Visual
VM the behavior, if you consistently run out of memory, then you may have a
leak.

Of course that you would be constrained by the fact of running a 32-bit or
64-bit Tomcat / Java environment.

On Fri, Jul 15, 2016 at 2:26 AM, Berneburg, Cris J. - US <
cberneb...@caci.com> wrote:

> Hi Folks
>
> I got this error from the Tomcat Web Application Manager after having
> stopped and started one of the applications multiple times.  (This was
> after repeatedly deploying the application manually to attempt to find a
> bug that I could not reproduce in my IDE.)  Once the error occurred, the
> server was extremely sluggish to respond even to remote desktop mouse and
> keyboard events.
>
> FYI, I deploy the app by stopping it on the Tomcat web manager, deleting
> almost everything out of the app folder using file manager, copying the new
> files and folders in, then starting the app from the Tomcat manager.
>
> Here's the error:
>
> FAIL - Application at context path /someapp could not be started
> FAIL - Encountered exception java.lang.OutOfMemoryError: PermGen space
>
> Is this likely due to a memory leak in my application?  Or does it have
> something to do with me doing so many repeated deployments?  Or perhaps
> simply from restarting the app so many times?  I might try an experiment to
> see how many times I can stop/start the app before the error next occurs.
>
> OS: Win Server 2012 R2
> Java: 1.6.0_24  (oops, need to upgrade that now)
> Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)
>
> --
> Cris Berneburg, Lead Software Engineer, CACI
>
>

Re: OutOfMemoryError: PermGen space

2016-07-14 Thread Mark Thomas

On 14/07/2016 20:26, Berneburg, Cris J. - US wrote:
> Hi Folks
> 
> I got this error from the Tomcat Web Application Manager after having stopped 
> and started one of the applications multiple times.  (This was after 
> repeatedly deploying the application manually to attempt to find a bug that I 
> could not reproduce in my IDE.)  Once the error occurred, the server was 
> extremely sluggish to respond even to remote desktop mouse and keyboard 
> events.
> 
> FYI, I deploy the app by stopping it on the Tomcat web manager, deleting 
> almost everything out of the app folder using file manager, copying the new 
> files and folders in, then starting the app from the Tomcat manager.
> 
> Here's the error:
> 
> FAIL - Application at context path /someapp could not be started
> FAIL - Encountered exception java.lang.OutOfMemoryError: PermGen space
> 
> Is this likely due to a memory leak in my application?

Yes.

>  Or does it have something to do with me doing so many repeated deployments?

Also yes.

>  Or perhaps simply from restarting the app so many times?

Stop/start has the same effect as redeploy in this case.

>  I might try an experiment to see how many times I can stop/start the app 
> before the error next occurs.
> 
> OS: Win Server 2012 R2
> Java: 1.6.0_24  (oops, need to upgrade that now)
> Tomcat: 6.0.37  (hmm... will need to upgrade soon-ish)

Indeed. Some upgrades are certainly in order. Not least because some of
the potential sources of memory leaks are JVM bugs that are fixed in the
lastest Java 8 releases.

This is probably a useful read:
http://people.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf

Despite the age, it is still very relevant today.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat

2010-11-23 Thread Mark Thomas

On 23/11/2010 06:55, Daniel Baktiar wrote:
 hi charles,
 
 please allow me to disagree to that hanging onto reference as the main
 issue.

Daniel,

You are completely wrong. I suggest you read this:
http://wiki.apache.org/tomcat/MemoryLeakProtection
and try out some of the sample code with a profiler.

 permgen space is garbage collector's specific issue, not general hanging
 onto reference issue. it is caused by redeployment, which is the metadata
 for classes, marked to be permanent generation by the hotspot garbage
 collector. when you deploy new classes, the class loader will introduce
 memory usages that will also marked as permanent generation.

That might have been true with the JVMs of 10 years ago. It certainly
isn't true today and hasn't been for quite some time.

Unused classes can be GC'd from permgen. If you don't believe me, get
yourself a profiler and test it for yourself.

 permgen is oracle hotspot specific implementation issue. you won't get it
 when you run on oracle jrockit (which performs just in time compilation),
 for example.

Yes you will see the exact same problem in JRockit. However, it will
take a lot longer since JRockit stores class information in the Java
heap. That means you still have a memory leak but it takes a lot longer
for it to trigger an OOME since you have to fill the entire heap first
rather than 'just' filling permgen.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-23 Thread xu cheng

 hi, Chuck.Caldarale
I referenced to these two links
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
and do as the blog tolds, but failed to find the reason of the oom of my
app...
thanks though..

by the way, do you have the the jhat the articals mentioned? I went to the
jdk/bin,
but the jhat there seems not work as the author mentioned.




2010/11/23 Daniel Baktiar dbakt...@gmail.com

 hi charles,

 please allow me to disagree to that hanging onto reference as the main
 issue.

 permgen space is garbage collector's specific issue, not general hanging
 onto reference issue. it is caused by redeployment, which is the metadata
 for classes, marked to be permanent generation by the hotspot garbage
 collector. when you deploy new classes, the class loader will introduce
 memory usages that will also marked as permanent generation.

 permgen is oracle hotspot specific implementation issue. you won't get it
 when you run on oracle jrockit (which performs just in time compilation),
 for example.
 ---
 daniel baktiar
 http://savinggaia.tritiumapps.com - saving the planet is everyone's
 business!




 On 23 November 2010 14:10, Caldarale, Charles R
 chuck.caldar...@unisys.comwrote:

   From: xu cheng [mailto:xcheng@gmail.com]
   Subject: Re: OutOfMemoryError some time on some tomcat1
 
   I just kept redeploying apps , and the perm gen keep
   growing each time I deploy the same app. and when I
   undeploy the app, the perm gen didn't clean the garbage
 
  Exactly the situation I suggested the other day: you have something
 that's
  hanging onto a reference to an object from your webapp classes,
 preventing
  the old webapp deployment from being garbage collected.  Again, read
 this:
 
  http://wiki.apache.org/tomcat/FAQ/Memory
 
  Also, take a look at these:
 
  http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
  http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
 
   - Chuck
 
 
  THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
  MATERIAL and is thus for use only by the intended recipient. If you
 received
  this in error, please contact the sender and delete the e-mail and its
  attachments from all computers.

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-23 Thread Daniel Baktiar

hi xu,

if you cannot find the jhat in the bin folder, most probably you were
referring to jre folder, instead of jdk folder.
i just checked it out, my jdk/bin folder has it, but not the case for my
jre/bin folder.

daniel
---
daniel baktiar
http://savinggaia.tritiumapps.com - saving the planet is everyone's
business!




On 23 November 2010 19:18, xu cheng xcheng@gmail.com wrote:

  hi, Chuck.Caldarale
 I referenced to these two links
 http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
 http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
 and do as the blog tolds, but failed to find the reason of the oom of my
 app...
 thanks though..

 by the way, do you have the the jhat the articals mentioned? I went to the
 jdk/bin,
 but the jhat there seems not work as the author mentioned.




 2010/11/23 Daniel Baktiar dbakt...@gmail.com

  hi charles,
 
  please allow me to disagree to that hanging onto reference as the main
  issue.
 
  permgen space is garbage collector's specific issue, not general hanging
  onto reference issue. it is caused by redeployment, which is the
 metadata
  for classes, marked to be permanent generation by the hotspot garbage
  collector. when you deploy new classes, the class loader will introduce
  memory usages that will also marked as permanent generation.
 
  permgen is oracle hotspot specific implementation issue. you won't get it
  when you run on oracle jrockit (which performs just in time compilation),
  for example.
  ---
  daniel baktiar
  http://savinggaia.tritiumapps.com - saving the planet is everyone's
  business!
 
 
 
 
  On 23 November 2010 14:10, Caldarale, Charles R
  chuck.caldar...@unisys.comwrote:
 
From: xu cheng [mailto:xcheng@gmail.com]
Subject: Re: OutOfMemoryError some time on some tomcat1
  
I just kept redeploying apps , and the perm gen keep
growing each time I deploy the same app. and when I
undeploy the app, the perm gen didn't clean the garbage
  
   Exactly the situation I suggested the other day: you have something
  that's
   hanging onto a reference to an object from your webapp classes,
  preventing
   the old webapp deployment from being garbage collected.  Again, read
  this:
  
   http://wiki.apache.org/tomcat/FAQ/Memory
  
   Also, take a look at these:
  
   http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
   http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
  
- Chuck
  
  
   THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
 PROPRIETARY
   MATERIAL and is thus for use only by the intended recipient. If you
  received
   this in error, please contact the sender and delete the e-mail and its
   attachments from all computers.

Re: OutOfMemoryError some time on some tomcat

2010-11-23 Thread Daniel Baktiar

hi mark,

thank you for showing my mistake. my apology to chuck also.
i will read the article.

---
daniel baktiar
http://savinggaia.tritiumapps.com - saving the planet is everyone's
business!




On 23 November 2010 18:50, Mark Thomas ma...@apache.org wrote:

 On 23/11/2010 06:55, Daniel Baktiar wrote:
  hi charles,
 
  please allow me to disagree to that hanging onto reference as the main
  issue.

 Daniel,

 You are completely wrong. I suggest you read this:
 http://wiki.apache.org/tomcat/MemoryLeakProtection
 and try out some of the sample code with a profiler.

  permgen space is garbage collector's specific issue, not general hanging
  onto reference issue. it is caused by redeployment, which is the
 metadata
  for classes, marked to be permanent generation by the hotspot garbage
  collector. when you deploy new classes, the class loader will introduce
  memory usages that will also marked as permanent generation.

 That might have been true with the JVMs of 10 years ago. It certainly
 isn't true today and hasn't been for quite some time.

 Unused classes can be GC'd from permgen. If you don't believe me, get
 yourself a profiler and test it for yourself.

  permgen is oracle hotspot specific implementation issue. you won't get it
  when you run on oracle jrockit (which performs just in time compilation),
  for example.

 Yes you will see the exact same problem in JRockit. However, it will
 take a lot longer since JRockit stores class information in the Java
 heap. That means you still have a memory leak but it takes a lot longer
 for it to trigger an OOME since you have to fill the entire heap first
 rather than 'just' filling permgen.

 Mark

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

RE: OutOfMemoryError some time on some tomcat!!!!1

2010-11-23 Thread Caldarale, Charles R

 From: xu cheng [mailto:xcheng@gmail.com] 
 Subject: Re: OutOfMemoryError some time on some tomcat1

  hanging onto a reference to an object from your webapp classes,
  preventing the old webapp deployment from being garbage collected.

 what kind of object do you mean by saying this?

Something is keeping a reference to an object (or class) defined in your 
webapp, or to the classloader for your webapp.  Likely candidates include 
thread locals, loggers, and auxiliary threads started (but not stopped) by the 
webapp.  Until the offending reference is nulled out, the object can't be 
collected, so its classloader can't be collected, so the old webapp stays in 
memory.

Any heap profiler should be able to find the references to your webapp classes, 
although the process may well be tedious.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-23 Thread Sylvain Laurent

Don't bother with jhat, try eclipse Memory Analysis Tool instead. It's much 
more friendly and efficient to find leaks.


On 23 nov. 2010, at 12:18, xu cheng wrote:

 hi, Chuck.Caldarale
 I referenced to these two links
 http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
 http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded
 and do as the blog tolds, but failed to find the reason of the oom of my
 app...
 thanks though..
 
 by the way, do you have the the jhat the articals mentioned? I went to the
 jdk/bin,
 but the jhat there seems not work as the author mentioned.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread Daniel Baktiar

hi xu cheng,

having a powerful machine with big memory is good. but don't assume that
everything will be used automatically.
the jvm doesn't automatically use all the resources in your memory when you
start tomcat. you need to configure it.
try to add something like this:
*CATALINA_OPTS=-XX:MaxPermSize=512m *
inside your catalina.sh (linux/unix) or catalina.bat (windows).
you can put this as the first line (after the comments, for example).

try to run again and see whether you still have the same error(s).

PermGen space is the permanent generational heap for storing data such as
class data. you will bump into this when deploying a large application or
deploying repetitively. you will still get the exception when deploying
often, only less frequent.
---
daniel baktiar
http://savinggaia.tritiumapps.com - saving the planet is everyone's
business!




2010/11/22 xu cheng xcheng@gmail.com

 after tracing the app with jprofiler for several hours , I still cannot
 figure the problem.
 it seems that the app doesn't use  a lot of memory.
 and it still run pretty well in my computer.and after it is deployed in the
 server, it crash
 the problem of the environment? but the tomcat on the server has been
 running for a really long time with out any problem
 what's the point?.oh no   (°ο°）

 2010/11/22 xu cheng xcheng@gmail.com

  by the way,
  it doesn't throws this exception while running on my computer
  it is only when the app is deploy on another computer that this problem
  occur
 
  2010/11/22 xu cheng xcheng@gmail.com
 
  hi:
  thanks for replying
  the app is running on a powerful server and the memory is suppose to be
  enough
  I'll check if there is a memory leak,(althouth the app is suppose to use
  only a few memory)
  thanks
 
  2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com
 
   From: xu cheng [mailto:xcheng@gmail.com]
   Subject: OutOfMemoryError some time on some tomcat1
 
   the app works pretty well on my pc, and the tomcat
   is apache-tomcat-6.0.29
   however , when I put this app on to another computer
   with the same tomcat it throws this exception
   Java HotSpot(TM) 64-Bit Server VM warning: Exception
   java.lang.OutOfMemoryError
 
   Exception in thread http-8080-24
   java.lang.OutOfMemoryError: PermGen space
 
  64-bit JVMs often require larger heap sizes than 32-bit ones.  If the
  error occurs on the first deployment of the app, you may just need to
  configure a larger PermGen.  However, if this error occurs only after
  redeploying your app some number of times, you likely have a memory
 leak.
   Use any of the widely available profilers or heap analysis tools to
 see
  just what is consuming memory.  You can get some pointers here:
 
  http://wiki.apache.org/tomcat/FAQ/Memory
 
   - Chuck
 
 
  THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
 PROPRIETARY
  MATERIAL and is thus for use only by the intended recipient. If you
 received
  this in error, please contact the sender and delete the e-mail and its
  attachments from all computers.
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread xu cheng

hi Daniel
thanks alot for replying.

I don't know how to figure out how much the param MaxPermSize is set to. may
be it's set to be default. I just set the xmx and xms, so I thought that the
memory will absolutely enough, I didn't
notice this param, my fault.

I did an experiment on tomcat , I just kept redeploying apps , and the perm
gen keep growing each time I deploy the same app. and when I undeploy the
app, the perm gen didn't clean the garbage
( I think they are garbage, but I don't know whether the vm can figure it
out, I monitor this with the
jconsole in the jdk/bin). in the meanwhile , the code cache in the memory
pool and the loaded classes grow with the same curve like the permanent
generation. the unused class meta data wasn't cleaned up during each
deployment.

I always redeploy the  apps with shutting down the server, I think that
might be the point.

by the way , this aritical help me a lot to understand it.
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

thanks again for helping

2010/11/23 Daniel Baktiar dbakt...@gmail.com

 hi xu cheng,

 having a powerful machine with big memory is good. but don't assume that
 everything will be used automatically.
 the jvm doesn't automatically use all the resources in your memory when you
 start tomcat. you need to configure it.
 try to add something like this:
 *CATALINA_OPTS=-XX:MaxPermSize=512m *
 inside your catalina.sh (linux/unix) or catalina.bat (windows).
 you can put this as the first line (after the comments, for example).

 try to run again and see whether you still have the same error(s).

 PermGen space is the permanent generational heap for storing data such as
 class data. you will bump into this when deploying a large application or
 deploying repetitively. you will still get the exception when deploying
 often, only less frequent.
 ---
 daniel baktiar
 http://savinggaia.tritiumapps.com - saving the planet is everyone's
 business!




 2010/11/22 xu cheng xcheng@gmail.com

  after tracing the app with jprofiler for several hours , I still cannot
  figure the problem.
  it seems that the app doesn't use  a lot of memory.
  and it still run pretty well in my computer.and after it is deployed in
 the
  server, it crash
  the problem of the environment? but the tomcat on the server has been
  running for a really long time with out any problem
  what's the point?.oh no   (°ο°）
 
  2010/11/22 xu cheng xcheng@gmail.com
 
   by the way,
   it doesn't throws this exception while running on my computer
   it is only when the app is deploy on another computer that this problem
   occur
  
   2010/11/22 xu cheng xcheng@gmail.com
  
   hi:
   thanks for replying
   the app is running on a powerful server and the memory is suppose to
 be
   enough
   I'll check if there is a memory leak,(althouth the app is suppose to
 use
   only a few memory)
   thanks
  
   2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com
  
From: xu cheng [mailto:xcheng@gmail.com]
Subject: OutOfMemoryError some time on some tomcat1
  
the app works pretty well on my pc, and the tomcat
is apache-tomcat-6.0.29
however , when I put this app on to another computer
with the same tomcat it throws this exception
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError
  
Exception in thread http-8080-24
java.lang.OutOfMemoryError: PermGen space
  
   64-bit JVMs often require larger heap sizes than 32-bit ones.  If the
   error occurs on the first deployment of the app, you may just need to
   configure a larger PermGen.  However, if this error occurs only after
   redeploying your app some number of times, you likely have a memory
  leak.
Use any of the widely available profilers or heap analysis tools to
  see
   just what is consuming memory.  You can get some pointers here:
  
   http://wiki.apache.org/tomcat/FAQ/Memory
  
- Chuck
  
  
   THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
  PROPRIETARY
   MATERIAL and is thus for use only by the intended recipient. If you
  received
   this in error, please contact the sender and delete the e-mail and
 its
   attachments from all computers.
  
  
   -
   To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread xu cheng

ps:
after several times of redeployment,
java.lang.OutOfMemoryError: PermGen space comes up.
I always redeploy the  apps *without* shutting down the server

在 2010年11月23日 下午1:50，xu cheng xcheng@gmail.com写道：

 hi Daniel
 thanks alot for replying.

 I don't know how to figure out how much the param MaxPermSize is set to.
 may be it's set to be default. I just set the xmx and xms, so I thought that
 the memory will absolutely enough, I didn't
 notice this param, my fault.

 I did an experiment on tomcat , I just kept redeploying apps , and the perm
 gen keep growing each time I deploy the same app. and when I undeploy the
 app, the perm gen didn't clean the garbage
 ( I think they are garbage, but I don't know whether the vm can figure it
 out, I monitor this with the
 jconsole in the jdk/bin). in the meanwhile , the code cache in the memory
 pool and the loaded classes grow with the same curve like the permanent
 generation. the unused class meta data wasn't cleaned up during each
 deployment.

 I always redeploy the  apps with shutting down the server, I think that
 might be the point.

 by the way , this aritical help me a lot to understand it.

 http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

 thanks again for helping

 2010/11/23 Daniel Baktiar dbakt...@gmail.com

 hi xu cheng,

 having a powerful machine with big memory is good. but don't assume that
 everything will be used automatically.
 the jvm doesn't automatically use all the resources in your memory when
 you
 start tomcat. you need to configure it.
 try to add something like this:
 *CATALINA_OPTS=-XX:MaxPermSize=512m *
 inside your catalina.sh (linux/unix) or catalina.bat (windows).
 you can put this as the first line (after the comments, for example).

 try to run again and see whether you still have the same error(s).

 PermGen space is the permanent generational heap for storing data such as
 class data. you will bump into this when deploying a large application or
 deploying repetitively. you will still get the exception when deploying
 often, only less frequent.
 ---
 daniel baktiar
 http://savinggaia.tritiumapps.com - saving the planet is everyone's
 business!




 2010/11/22 xu cheng xcheng@gmail.com

  after tracing the app with jprofiler for several hours , I still cannot
  figure the problem.
  it seems that the app doesn't use  a lot of memory.
  and it still run pretty well in my computer.and after it is deployed in
 the
  server, it crash
  the problem of the environment? but the tomcat on the server has been
  running for a really long time with out any problem
  what's the point?.oh no   (°ο°）
 
  2010/11/22 xu cheng xcheng@gmail.com
 
   by the way,
   it doesn't throws this exception while running on my computer
   it is only when the app is deploy on another computer that this
 problem
   occur
  
   2010/11/22 xu cheng xcheng@gmail.com
  
   hi:
   thanks for replying
   the app is running on a powerful server and the memory is suppose to
 be
   enough
   I'll check if there is a memory leak,(althouth the app is suppose to
 use
   only a few memory)
   thanks
  
   2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com
  
From: xu cheng [mailto:xcheng@gmail.com]
Subject: OutOfMemoryError some time on some tomcat1
  
the app works pretty well on my pc, and the tomcat
is apache-tomcat-6.0.29
however , when I put this app on to another computer
with the same tomcat it throws this exception
Java HotSpot(TM) 64-Bit Server VM warning: Exception
java.lang.OutOfMemoryError
  
Exception in thread http-8080-24
java.lang.OutOfMemoryError: PermGen space
  
   64-bit JVMs often require larger heap sizes than 32-bit ones.  If
 the
   error occurs on the first deployment of the app, you may just need
 to
   configure a larger PermGen.  However, if this error occurs only
 after
   redeploying your app some number of times, you likely have a memory
  leak.
Use any of the widely available profilers or heap analysis tools to
  see
   just what is consuming memory.  You can get some pointers here:
  
   http://wiki.apache.org/tomcat/FAQ/Memory
  
- Chuck
  
  
   THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
  PROPRIETARY
   MATERIAL and is thus for use only by the intended recipient. If you
  received
   this in error, please contact the sender and delete the e-mail and
 its
   attachments from all computers.
  
  
  
 -
   To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
   For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread Daniel Baktiar

hi xu cheng,

don't mention it.
glad you've eventually solved your problem.

daniel

---
daniel baktiar
http://savinggaia.tritiumapps.com - saving the planet is everyone's
business!




2010/11/23 xu cheng xcheng@gmail.com

 hi Daniel
 thanks alot for replying.

 I don't know how to figure out how much the param MaxPermSize is set to.
 may be it's set to be default. I just set the xmx and xms, so I thought that
 the memory will absolutely enough, I didn't
 notice this param, my fault.

 I did an experiment on tomcat , I just kept redeploying apps , and the perm
 gen keep growing each time I deploy the same app. and when I undeploy the
 app, the perm gen didn't clean the garbage
 ( I think they are garbage, but I don't know whether the vm can figure it
 out, I monitor this with the
 jconsole in the jdk/bin). in the meanwhile , the code cache in the memory
 pool and the loaded classes grow with the same curve like the permanent
 generation. the unused class meta data wasn't cleaned up during each
 deployment.

 I always redeploy the  apps with shutting down the server, I think that
 might be the point.

 by the way , this aritical help me a lot to understand it.

 http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

 thanks again for helping

 2010/11/23 Daniel Baktiar dbakt...@gmail.com

 hi xu cheng,

 having a powerful machine with big memory is good. but don't assume that
 everything will be used automatically.
 the jvm doesn't automatically use all the resources in your memory when
 you
 start tomcat. you need to configure it.
 try to add something like this:
 *CATALINA_OPTS=-XX:MaxPermSize=512m *
 inside your catalina.sh (linux/unix) or catalina.bat (windows).
 you can put this as the first line (after the comments, for example).

 try to run again and see whether you still have the same error(s).

 PermGen space is the permanent generational heap for storing data such as
 class data. you will bump into this when deploying a large application or
 deploying repetitively. you will still get the exception when deploying
 often, only less frequent.
 ---
 daniel baktiar
 http://savinggaia.tritiumapps.com - saving the planet is everyone's
 business!

RE: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread Caldarale, Charles R

 From: xu cheng [mailto:xcheng@gmail.com] 
 Subject: Re: OutOfMemoryError some time on some tomcat1

 I just kept redeploying apps , and the perm gen keep 
 growing each time I deploy the same app. and when I 
 undeploy the app, the perm gen didn't clean the garbage

Exactly the situation I suggested the other day: you have something that's 
hanging onto a reference to an object from your webapp classes, preventing the 
old webapp deployment from being garbage collected.  Again, read this:

http://wiki.apache.org/tomcat/FAQ/Memory

Also, take a look at these:

http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread xu cheng

hi:
thanks for the references. I 'll read that.
by the way,
*hanging onto a reference to an object from your webapp classes, preventing
the old webapp deployment from being garbage collected. *

what kind of object do you mean by saying this? classes relevant to the
class loader? or something else? for example?
thanks


2010/11/23 Caldarale, Charles R chuck.caldar...@unisys.com

  From: xu cheng [mailto:xcheng@gmail.com]
  Subject: Re: OutOfMemoryError some time on some tomcat1

  I just kept redeploying apps , and the perm gen keep
  growing each time I deploy the same app. and when I
  undeploy the app, the perm gen didn't clean the garbage

 Exactly the situation I suggested the other day: you have something that's
 hanging onto a reference to an object from your webapp classes, preventing
 the old webapp deployment from being garbage collected.  Again, read this:

 http://wiki.apache.org/tomcat/FAQ/Memory

 Also, take a look at these:

 http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
 http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-22 Thread Daniel Baktiar

hi charles,

please allow me to disagree to that hanging onto reference as the main
issue.

permgen space is garbage collector's specific issue, not general hanging
onto reference issue. it is caused by redeployment, which is the metadata
for classes, marked to be permanent generation by the hotspot garbage
collector. when you deploy new classes, the class loader will introduce
memory usages that will also marked as permanent generation.

permgen is oracle hotspot specific implementation issue. you won't get it
when you run on oracle jrockit (which performs just in time compilation),
for example.
---
daniel baktiar
http://savinggaia.tritiumapps.com - saving the planet is everyone's
business!




On 23 November 2010 14:10, Caldarale, Charles R
chuck.caldar...@unisys.comwrote:

  From: xu cheng [mailto:xcheng@gmail.com]
  Subject: Re: OutOfMemoryError some time on some tomcat1

  I just kept redeploying apps , and the perm gen keep
  growing each time I deploy the same app. and when I
  undeploy the app, the perm gen didn't clean the garbage

 Exactly the situation I suggested the other day: you have something that's
 hanging onto a reference to an object from your webapp classes, preventing
 the old webapp deployment from being garbage collected.  Again, read this:

 http://wiki.apache.org/tomcat/FAQ/Memory

 Also, take a look at these:

 http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
 http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.

RE: OutOfMemoryError some time on some tomcat!!!!1

2010-11-21 Thread Caldarale, Charles R

 From: xu cheng [mailto:xcheng@gmail.com] 
 Subject: OutOfMemoryError some time on some tomcat1

 the app works pretty well on my pc, and the tomcat 
 is apache-tomcat-6.0.29
 however , when I put this app on to another computer
 with the same tomcat it throws this exception
 Java HotSpot(TM) 64-Bit Server VM warning: Exception
 java.lang.OutOfMemoryError

 Exception in thread http-8080-24 
 java.lang.OutOfMemoryError: PermGen space

64-bit JVMs often require larger heap sizes than 32-bit ones.  If the error 
occurs on the first deployment of the app, you may just need to configure a 
larger PermGen.  However, if this error occurs only after redeploying your app 
some number of times, you likely have a memory leak.  Use any of the widely 
available profilers or heap analysis tools to see just what is consuming 
memory.  You can get some pointers here:

http://wiki.apache.org/tomcat/FAQ/Memory

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-21 Thread xu cheng

hi:
thanks for replying
the app is running on a powerful server and the memory is suppose to be
enough
I'll check if there is a memory leak,(althouth the app is suppose to use
only a few memory)
thanks

2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com

  From: xu cheng [mailto:xcheng@gmail.com]
  Subject: OutOfMemoryError some time on some tomcat1

  the app works pretty well on my pc, and the tomcat
  is apache-tomcat-6.0.29
  however , when I put this app on to another computer
  with the same tomcat it throws this exception
  Java HotSpot(TM) 64-Bit Server VM warning: Exception
  java.lang.OutOfMemoryError

  Exception in thread http-8080-24
  java.lang.OutOfMemoryError: PermGen space

 64-bit JVMs often require larger heap sizes than 32-bit ones.  If the error
 occurs on the first deployment of the app, you may just need to configure a
 larger PermGen.  However, if this error occurs only after redeploying your
 app some number of times, you likely have a memory leak.  Use any of the
 widely available profilers or heap analysis tools to see just what is
 consuming memory.  You can get some pointers here:

 http://wiki.apache.org/tomcat/FAQ/Memory

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-21 Thread xu cheng

by the way,
it doesn't throws this exception while running on my computer
it is only when the app is deploy on another computer that this problem
occur

2010/11/22 xu cheng xcheng@gmail.com

 hi:
 thanks for replying
 the app is running on a powerful server and the memory is suppose to be
 enough
 I'll check if there is a memory leak,(althouth the app is suppose to use
 only a few memory)
 thanks

 2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com

  From: xu cheng [mailto:xcheng@gmail.com]
  Subject: OutOfMemoryError some time on some tomcat1

  the app works pretty well on my pc, and the tomcat
  is apache-tomcat-6.0.29
  however , when I put this app on to another computer
  with the same tomcat it throws this exception
  Java HotSpot(TM) 64-Bit Server VM warning: Exception
  java.lang.OutOfMemoryError

  Exception in thread http-8080-24
  java.lang.OutOfMemoryError: PermGen space

 64-bit JVMs often require larger heap sizes than 32-bit ones.  If the
 error occurs on the first deployment of the app, you may just need to
 configure a larger PermGen.  However, if this error occurs only after
 redeploying your app some number of times, you likely have a memory leak.
  Use any of the widely available profilers or heap analysis tools to see
 just what is consuming memory.  You can get some pointers here:

 http://wiki.apache.org/tomcat/FAQ/Memory

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError some time on some tomcat!!!!1

2010-11-21 Thread xu cheng

after tracing the app with jprofiler for several hours , I still cannot
figure the problem.
it seems that the app doesn't use  a lot of memory.
and it still run pretty well in my computer.and after it is deployed in the
server, it crash
the problem of the environment? but the tomcat on the server has been
running for a really long time with out any problem
what's the point?.oh no   (°ο°）

2010/11/22 xu cheng xcheng@gmail.com

 by the way,
 it doesn't throws this exception while running on my computer
 it is only when the app is deploy on another computer that this problem
 occur

 2010/11/22 xu cheng xcheng@gmail.com

 hi:
 thanks for replying
 the app is running on a powerful server and the memory is suppose to be
 enough
 I'll check if there is a memory leak,(althouth the app is suppose to use
 only a few memory)
 thanks

 2010/11/22 Caldarale, Charles R chuck.caldar...@unisys.com

  From: xu cheng [mailto:xcheng@gmail.com]
  Subject: OutOfMemoryError some time on some tomcat1

  the app works pretty well on my pc, and the tomcat
  is apache-tomcat-6.0.29
  however , when I put this app on to another computer
  with the same tomcat it throws this exception
  Java HotSpot(TM) 64-Bit Server VM warning: Exception
  java.lang.OutOfMemoryError

  Exception in thread http-8080-24
  java.lang.OutOfMemoryError: PermGen space

 64-bit JVMs often require larger heap sizes than 32-bit ones.  If the
 error occurs on the first deployment of the app, you may just need to
 configure a larger PermGen.  However, if this error occurs only after
 redeploying your app some number of times, you likely have a memory leak.
  Use any of the widely available profilers or heap analysis tools to see
 just what is consuming memory.  You can get some pointers here:

 http://wiki.apache.org/tomcat/FAQ/Memory

  - Chuck


 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you received
 this in error, please contact the sender and delete the e-mail and its
 attachments from all computers.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-16 Thread abhishek jain

hi
ps axf --cols 1000 | grep java returns

29807 pts/2S+ 0:00  \_ grep java
19511 ?Ss 0:00 jsvc.exec -user tomcat -cp ./bootstrap.jar
-Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
-errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
-security
19512 ?Sl11:57  \_ jsvc.exec -user tomcat -cp ./bootstrap.jar
-Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
-errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
-security

and echo $JAVA_OPTS

returns a blank line
Pl advice what should i do,
thanks
abhi


On Wed, Sep 15, 2010 at 6:06 PM, Peter McNeil pe...@mcneils.net wrote:

 Check the process for java has the correct max perm size set. If you're
 using linux do a

 ps axf --cols 1000 | grep java

 A max PermSize of 1024m is pretty big...
 My tomcat 6 instance running several apps returns:-

  /usr/java/latest/bin/java
 -Djava.util.logging.config.file=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/conf/logging.properties
 -server -Xmx2000m -XX:MaxPermSize=400m
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 -Djava.endorsed.dirs=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/endorsed
 -classpath /home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/bin/bootstrap.jar
 -Dcatalina.base=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24
 -Dcatalina.home=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24
 -Djava.io.tmpdir=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/temp
 org.apache.catalina.startup.Bootstrap start

 and my JAVA_OPTS is ...
 echo $JAVA_OPTS
 -server -Xmx2000m -XX:MaxPermSize=400m

 If that all looks OK you have a memory leak, try using jconsole and look at
 threads and deadlocks etc.

 Good luck,
 Peter.


 On 15/09/10 16:28, abhishek jain wrote:

 Hi,
 i have the following in bin/catalina.sh

   JAVA_OPTS=$JAVA_OPTS -server -Xms512M -Xmx1024M -XX:MaxPermSize=1024M
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

 still i get the permgen error exception everyday, pl. someone help, i have
 about 7 applications in struts running on the server, the applications are
 in struts 1.2 , mysql, tomcat 5.5, and are not big applications with about
 only a few jsps.

 I consider the applications written properly, pl. help,

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-16 Thread André Warnier


abhishek jain wrote:

hi
ps axf --cols 1000 | grep java returns

29807 pts/2S+ 0:00  \_ grep java
19511 ?Ss 0:00 jsvc.exec -user tomcat -cp ./bootstrap.jar
-Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
-errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
-security
19512 ?Sl11:57  \_ jsvc.exec -user tomcat -cp ./bootstrap.jar
-Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
-errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
-security

and echo $JAVA_OPTS

returns a blank line
Pl advice what should i do,


Obviously on your system (a Linux or Unix -like system), Tomcat is being started using 
jsvc as a wrapper for the java JVM.


jsvc is not a part of Tomcat. If your system uses it to start Tomcat, it is because the 
creators of the Tomcat package for your platform have decided to use it.


You should probably start by reading the jsvc documentation, at :
http://commons.apache.org/daemon/
Read the introduction on this page, and then follow the link to jsvc.
This will really clear things up, and will tell you also how to provide start-up 
parameters to jsvc, so that it starts java in the way you want, with the options you want.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-16 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

abhi,

On 9/16/2010 3:21 AM, abhishek jain wrote:
 hi
 ps axf --cols 1000 | grep java returns
 
 29807 pts/2S+ 0:00  \_ grep java
 19511 ?Ss 0:00 jsvc.exec -user tomcat -cp ./bootstrap.jar
 -Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
 -errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
 -security
 19512 ?Sl11:57  \_ jsvc.exec -user tomcat -cp ./bootstrap.jar
 -Djava.endorsed.dirs=../common/endorsed -outfile ../logs/catalina.out
 -errfile ../logs/catalina.err -verbose org.apache.catalina.startup.Bootstrap
 -security
 
 and echo $JAVA_OPTS
 
 returns a blank line
 Pl advice what should i do,

Try these:

$ jps
(sample output)
13747 Bootstrap
3254 Bootstrap
31762 Bootstrap
32352 Jps

Then, choose which one you want to inspect and do:

$ jinfo 13747
Attaching to process ID 13747, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 16.3-b01
Java System Properties:

java.runtime.name = Java(TM) SE Runtime Environment
sun.boot.library.path = /usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/i386
java.vm.version = 16.3-b01
shared.loader =
java.vm.vendor = Sun Microsystems Inc.
java.vendor.url = http://java.sun.com/
path.separator = :
tomcat.util.buf.StringCache.byte.enabled = true
java.vm.name = Java HotSpot(TM) Server VM
file.encoding.pkg = sun.io
sun.java.launcher = SUN_STANDARD
user.country = US
sun.os.patch.level = unknown
java.vm.specification.name = Java Virtual Machine Specification
user.dir = /...
java.runtime.version = 1.6.0_20-b02
java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment
java.endorsed.dirs = /usr/local/apache-tomcat-6.0.26/endorsed
os.arch = i386
java.io.tmpdir = /...
line.separator =

java.vm.specification.vendor = Sun Microsystems Inc.
java.naming.factory.url.pkgs = org.apache.naming
java.util.logging.manager = org.apache.juli.ClassLoaderLogManager
os.name = Linux
sun.jnu.encoding = UTF-8
java.library.path = /usr/local/apache-tomcat-6.0.26/server/lib
java.specification.name = Java Platform API Specification
java.class.version = 50.0
org.apache.catalina.STRICT_SERVLET_COMPLIANCE = true
sun.management.compiler = HotSpot Tiered Compilers
os.version = 2.6.18-14-fza-686-bigmem
user.home = /home/cschultz
catalina.useNaming = true
user.timezone = America/New_York
java.awt.printerjob = sun.print.PSPrinterJob
file.encoding = UTF-8
java.specification.version = 1.6
catalina.home = /usr/local/apache-tomcat-6.0.26
java.class.path = /usr/local/apache-tomcat-6.0.26/bin/bootstrap.jar
user.name = cschultz
java.naming.factory.initial = org.apache.naming.java.javaURLContextFactory
package.definition =
sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.
java.vm.specification.version = 1.0
java.home = /usr/lib/jvm/java-6-sun-1.6.0.20/jre
sun.arch.data.model = 32
user.language = en
java.specification.vendor = Sun Microsystems Inc.
java.vm.info = mixed mode
java.version = 1.6.0_20
java.ext.dirs =
/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/ext:/usr/java/packages/lib/ext
sun.boot.class.path =
/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/resources.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/rt.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/jsse.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/jce.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/lib/charsets.jar:/usr/lib/jvm/java-6-sun-1.6.0.20/jre/classes
server.loader =
java.vendor = Sun Microsystems Inc.
catalina.base = /...
nop =
file.separator = /
java.vendor.url.bug = http://java.sun.com/cgi-bin/bugreport.cgi
common.loader = ${catalina.home}/lib,${catalina.home}/lib/*.jar
sun.io.unicode.encoding = UnicodeLittle
sun.cpu.endian = little
package.access =
sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
sun.cpu.isalist =

VM Flags:

- -Dnop -Xmx64M
- -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
- -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
- -Djava.library.path=/usr/local/apache-tomcat-6.0.26/server/lib
- -Djava.endorsed.dirs=/usr/local/apache-tomcat-6.0.26/endorsed
- -Dcatalina.base=/... -Dcatalina.home=/usr/local/apache-tomcat-6.0.26
- -Djava.io.tmpdir=/...


And try this one:

$ jmap -heap 13747
Attaching to process ID 13747, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 16.3-b01

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize  = 67108864 (64.0MB)
   NewSize  = 4194304 (4.0MB)
   MaxNewSize   = 4294901760 (4095.9375MB)
   OldSize  = 4194304 (4.0MB)
   NewRatio = 2
   SurvivorRatio= 8
   PermSize = 16777216 (16.0MB)
   MaxPermSize  = 67108864 (64.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 1900544 (1.8125MB)
   used = 384080

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-15 Thread Peter McNeil

Check the process for java has the correct max perm size set. If you're 
using linux do a


ps axf --cols 1000 | grep java

A max PermSize of 1024m is pretty big...
My tomcat 6 instance running several apps returns:-

 /usr/java/latest/bin/java 
-Djava.util.logging.config.file=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/conf/logging.properties 
-server -Xmx2000m -XX:MaxPermSize=400m 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager 
-Djava.endorsed.dirs=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/endorsed 
-classpath 
/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/bin/bootstrap.jar 
-Dcatalina.base=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24 
-Dcatalina.home=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24 
-Djava.io.tmpdir=/home/pmcneil/apps/tomcat/apache-tomcat-6.0.24/temp 
org.apache.catalina.startup.Bootstrap start


and my JAVA_OPTS is ...
echo $JAVA_OPTS
-server -Xmx2000m -XX:MaxPermSize=400m

If that all looks OK you have a memory leak, try using jconsole and look 
at threads and deadlocks etc.


Good luck,
Peter.

On 15/09/10 16:28, abhishek jain wrote:

Hi,
i have the following in bin/catalina.sh

   JAVA_OPTS=$JAVA_OPTS -server -Xms512M -Xmx1024M -XX:MaxPermSize=1024M
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

still i get the permgen error exception everyday, pl. someone help, i have
about 7 applications in struts running on the server, the applications are
in struts 1.2 , mysql, tomcat 5.5, and are not big applications with about
only a few jsps.

I consider the applications written properly, pl. help,

   



--
web: http://nerderg.com
Twitter: http://twitter.com/pmcneil


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-15 Thread Edmund Urbani

 On 09/15/10 08:28, abhishek jain wrote:
 Hi,
 i have the following in bin/catalina.sh

   JAVA_OPTS=$JAVA_OPTS -server -Xms512M -Xmx1024M -XX:MaxPermSize=1024M
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

 still i get the permgen error exception everyday, pl. someone help, i have
 about 7 applications in struts running on the server, the applications are
 in struts 1.2 , mysql, tomcat 5.5, and are not big applications with about
 only a few jsps.

 I consider the applications written properly, pl. help,

A few things that can fill PermGen space are...
- repeated re-deployment of applications in tomcat
- dynamically generating classes/JSP pages
- doing really weird stuff with the classloader(s)

Unless you are doing any of the above, I would try and monitor PermGen space
usage in jconsole for a while. You might also want to consider separating those
applications into several tomcat instances to narrow down the cause.

Cheers,
 Edmund

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: OutOfMemoryError: PermGen space!!!! Dont know why?

2010-09-15 Thread Pid

On 15/09/2010 07:28, abhishek jain wrote:
 Hi,
 i have the following in bin/catalina.sh
 
   JAVA_OPTS=$JAVA_OPTS -server -Xms512M -Xmx1024M -XX:MaxPermSize=1024M
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
 
 still i get the permgen error exception everyday, pl. someone help, i have
 about 7 applications in struts running on the server, the applications are
 in struts 1.2 , mysql, tomcat 5.5, and are not big applications with about
 only a few jsps.

Tomcat 5.5.what?

 I consider the applications written properly, pl. help,

When did this problem start?

Have you actually got enough free memory available?

Are you reloading the application, or updating JSPs regularly?


p


0x62590808.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: OutOfMemoryError happening in embedded instance of Tomcat 6 (Apache OFBiz project)

2008-07-08 Thread Jacopo Cappellato


Filip,

thank you for your help.
Your suggestion actually helped to identify the root of our issues: it  
was not related to Tomcat 6 but instead it was an issue in the version  
of DBCP we were using (a snapshot of November 2007); we have upgraded  
it to the HEAD and the errors seem gone away (we are running some load  
testing sessions right now).


Thanks so much and sorry for the off-topic.

Jacopo


On Jul 7, 2008, at 6:03 PM, Filip Hanik - Dev Lists wrote:

just use the -XX:+HeapDumpOnOutOfMemoryError and see what is causing  
the OOME


Filip

Jacopo Cappellato wrote:

Hi all,

I am one of the committers and PMC member of the Apache OFBiz  
project (ofbiz.apache.org).
Our project is using an embedded instance of Tomcat to run the web  
applications that compose the OFBiz suite of ERP applications.


A few weeks ago, with rev. 659490, we have upgraded Tomcat from to  
5.5.23 to 6.0.16.
Since then, we have noticed in some production server some  
OutOfMemoryError: Java heap space exceptions that make the  
instances pretty unstable after some time they are up.
My suspect is that we are not creating the Tomcat instance in the  
right way, but I am not sure where is the error... and I'm not sure  
about the question I should ask here.

However, maybe someone of you could help with some advices or hints.

This is the code we used to create the instance of Tomcat 5.5.23  
(that was working fine):


http://svn.apache.org/viewvc/ofbiz/trunk/framework/catalina/src/org/ofbiz/catalina/container/CatalinaContainer.java?revision=585848view=markup

and this is the new code for 6.0.16:

http://svn.apache.org/viewvc/ofbiz/trunk/framework/catalina/src/org/ofbiz/catalina/container/CatalinaContainer.java?view=markup

Thanks so much,

Jacopo



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError happening in embedded instance of Tomcat 6 (Apache OFBiz project)

2008-07-07 Thread Filip Hanik - Dev Lists

just use the -XX:+HeapDumpOnOutOfMemoryError and see what is causing the
OOME

Filip

Jacopo Cappellato wrote:

Hi all,

I am one of the committers and PMC member of the Apache OFBiz project
(ofbiz.apache.org).
Our project is using an embedded instance of Tomcat to run the web
applications that compose the OFBiz suite of ERP applications.

A few weeks ago, with rev. 659490, we have upgraded Tomcat from to
5.5.23 to 6.0.16.
Since then, we have noticed in some production server some
OutOfMemoryError: Java heap space exceptions that make the instances
pretty unstable after some time they are up.
My suspect is that we are not creating the Tomcat instance in the
right way, but I am not sure where is the error... and I'm not sure
about the question I should ask here.

However, maybe someone of you could help with some advices or hints.

This is the code we used to create the instance of Tomcat 5.5.23 (that
was working fine):

http://svn.apache.org/viewvc/ofbiz/trunk/framework/catalina/src/org/ofbiz/catalina/container/CatalinaContainer.java?revision=585848view=markup

and this is the new code for 6.0.16:

http://svn.apache.org/viewvc/ofbiz/trunk/framework/catalina/src/org/ofbiz/catalina/container/CatalinaContainer.java?view=markup

Thanks so much,

Jacopo

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError while deploying

2008-06-10 Thread Filip Hanik - Dev Lists


could you be running into
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332094

so an upgrade to the JVM might fix it

Filip

Reid Swanson wrote:

Hi,

I have a web app that includes a large amount of data and I am having trouble
deploying it. Nearly every time I try it fails with the following error.

SEVERE: HTMLManager: FAIL - Deploy Upload Failed, Exception: Error invoking
method check
javax.management.RuntimeErrorException: Error invoking method check
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:308)
at
com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
at 
org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1465)
at
org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:243)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.OutOfMemoryError
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:203)
at java.util.jar.JarFile.init(JarFile.java:132)
at java.util.jar.JarFile.init(JarFile.java:97)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:746)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:515)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1229)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:297)
... 21 more

I am running Mac OSX 10.4.11

with
java version 1.5.0_07
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode)

and tomcat 6.0.16

I've defined JAVA_OPTS to

JAVA_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=512m -XX:PermSize=256m
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled 
-XX:+CMSClassUnloadingEnabled

But basically no matter what I set JAVA_OPTS to the deployment will fail and the
JVM never seems to use more than about 70MB of memory.

Any help would be greatly appreciated.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError while deploying

2008-06-10 Thread Reid Swanson

It's possible. Unfortunately it's not really practical to upgrade the JVM on the
machine. As a work around I've found I can manually unzip the war and set the
directory and context path in the html manager.

On Tue 06/10/08  9:43 AM , Filip Hanik - Dev Lists [EMAIL PROTECTED] sent:
 could you be running into
 
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6332094
 
 
 so an upgrade to the JVM might fix it
 
 
 
 Filip
 
 
 
 Reid Swanson wrote:
 
  Hi,
 
 
 
  I have a web app that includes a large amount of data
 and I am having trouble
  deploying it. Nearly every time I try it fails with the
 following error.
 
 
  SEVERE: HTMLManager: FAIL - Deploy Upload Failed,
 Exception: Error invoking
  method check
 
  javax.management.RuntimeErrorException: Error invoking
 method check
  at
 
 
 org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:30
 8)
  at
 
 
 com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java
 :213)
  at
 com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
  at
 
 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanSe
 rverInterceptor.java:815)
  at
 com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784)
  at
 org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1465)
  at
 
 
 org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.ja
 va:243)
  at
 javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
  at
 javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
  at
 
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio
 nFilterChain.java:290)
  at
 
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC
 hain.java:206)
  at
 
 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j
 ava:233)
  at
 
 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j
 ava:175)
  at
 
 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBas
 e.java:525)
  at
 
 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12
 8)
  at
 
 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:10
 2)
  at
 
 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav
 a:109)
  at
 
 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
  at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
  at
 
 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Htt
 p11Protocol.java:583)
  at
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
  at java.lang.Thread.run(Thread.java:613)
 
  Caused by: java.lang.OutOfMemoryError
 
  at java.util.zip.ZipFile.open(Native Method)
 
  at
 java.util.zip.ZipFile.(ZipFile.java:203)
  at
 java.util.jar.JarFile.(JarFile.java:132)
  at
 java.util.jar.JarFile.(JarFile.java:97)
  at
 org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:746)
  at
 org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:515)
  at
 org.apache.catalina.startup.HostConfig.check(HostConfig.java:1229)
  at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
 
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
 9)
  at
 
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
 l.java:25)
  at
 java.lang.reflect.Method.invoke(Method.java:585)
  at
 
 
 org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:29
 7)
  ... 21 more
 
 
 
  I am running Mac OSX 10.4.11
 
 
 
  with
 
  java version 1.5.0_07
 
  Java(TM) 2 Runtime Environment, Standard Edition (build
 1.5.0_07-164)
  Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed
 mode)
 
 
  and tomcat 6.0.16
 
 
 
  I've defined JAVA_OPTS to
 
 
 
  JAVA_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=512m
 -XX:PermSize=256m
  -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled
 -XX:+CMSClassUnloadingEnabled
 
 
  But basically no matter what I set JAVA_OPTS to the
 deployment will fail and the
  JVM never seems to use more than about 70MB of memory.
 
 
 
  Any help would be greatly appreciated.
 
 
 
 
 
 
 -
  To start a new topic, e-mail: users
 @tomcat.apache.org
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: 
 [EMAIL PROTECTED]
 
 
 
 
 
 

 
 
 
 
 
 -
 
 To start a new topic, e-mail: users
 @tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL

Re: OutOfMemoryError: allocLargeObjectOrArray

2008-01-30 Thread David Delbecq

This is an internal jvm error. It seems you activated swallowoutput on 
your context which makes tomcat reidrect stdout and stderr to an 
internal buffer during servlet excecution and later pass it to a logger. 
Your servlet is making lots of outputs (75Megs of data) according to 
your error, and there is not anough room to convert that to a String 
prior to sending it to a logger. I suggest you remove that context 
attribute and then inspect catalina.out for the messages of your servlet.



En l'instant précis du 30/01/08 08:48, [EMAIL PROTECTED] s'exprimait 
en ces termes:

Dear all:
We have some problem with OutOfMemory error.
Environment
Tomcat: 5.5.25
JDK: jrockit-R27.4.0-jdk1.5.0_12


5130472 [TP-Processor29] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/Mainweb].[default]
 - Servlet.service() for servlet default threw exception
java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size:
75333648, Num elements: 37666816
at java.lang.String.init(String.java:458)
at
java.io.ByteArrayOutputStream.toString(ByteArrayOutputStream.java:160)
at
org.apache.tomcat.util.log.CaptureLog.getCapture(CaptureLog.java:48)
at
org.apache.tomcat.util.log.SystemLogHandler.stopCapture(SystemLogHandler.java:109)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:207)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.jstripe.tomcat.probe.Tomcat55AgentValve.invoke(Tomcat55AgentValve.java:20)
at
org.apache.catalina.cluster.tcp.ReplicationValve.invoke(ReplicationValve.java:347)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
==
java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size:
75333648, Num elements: 37666816
   What does it mean about  allocLargeObjectOrArray ?
   I have tried to tune jvm options with -server -Xms768m -Xmx768m
-Xns256m
  But tomcat still throw out the same error
  Any suggestion will be appreciated ^^



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
  



--
http://www.devlog.be (a belgian developer's logs)



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError: allocLargeObjectOrArray

2008-01-30 Thread Caldarale, Charles R

 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Subject: OutOfMemoryError: allocLargeObjectOrArray

 JDK: jrockit-R27.4.0-jdk1.5.0_12
 java.lang.OutOfMemoryError: allocLargeObjectOrArray - Object size:
 75333648, Num elements: 37666816

1) Try increasing your heap size.

2) Try a Sun JVM rather than JRockit.  The HotSpot allocation and
garbage collection policies are quite different from those used by
JRockit.

3) Fix your webapp to chunk the output rather than sending it all in one
go.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError

2007-03-21 Thread Haroon Rafique

On Yesterday at 2:54pm, FHDL=Filip Hanik - Dev Lists [EMAIL PROTECTED]...:

FHDL java.lang.OutOfMemoryError: unable to create new native thread
FHDL 
FHDL There is not enough space to create a new thread. Threads(stacks).
FHDL if -Xmx solves your problem, then set it and be happy :)
FHDL 
FHDL another tip is to decrease the value of your thread stack size using the
FHDL -Xss parameter, for example
FHDL -Xss32k is one value
FHDL 

That would be my recommendation as well (that's twice now - I replied to 
an earlier email in this thread with the same advice). That's what solved 
the problem for me on a similar configuation.

FHDL How many threads are you creating?
FHDL 
FHDL Filip

Later,
--
Haroon Rafique
[EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError

2007-03-20 Thread Filip Hanik - Dev Lists


java.lang.OutOfMemoryError: unable to create new native thread


There is not enough space to create a new thread. Threads(stacks).
if -Xmx solves your problem, then set it and be happy :)

another tip is to decrease the value of your thread stack size using the -Xss 
parameter, for example
-Xss32k is one value

How many threads are you creating?

Filip



Rahul Tandon wrote:

Hi All,

 


If I don't give -Xmx option in CATALINA_OPTS, then it hangs and Catalina.out
has following error message:

 

 


java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)

at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Caused by: java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:574)

at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.init(ThreadPool.
java:643)

at
org.apache.tomcat.util.threads.ThreadPool.openThreads(ThreadPool.java:515)

at
org.apache.tomcat.util.threads.ThreadPool.start(ThreadPool.java:148)

at
org.apache.tomcat.util.net.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoint.jav
a:315)

at
org.apache.coyote.http11.Http11BaseProtocol.start(Http11BaseProtocol.java:15
0)

at
org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:75)

at
org.apache.catalina.connector.Connector.start(Connector.java:1089)

at
org.apache.catalina.core.StandardService.start(StandardService.java:459)

at
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)

at org.apache.catalina.startup.Catalina.start(Catalina.java:551)

... 6 more

 

 


Any clue?

 

 


Thanks,

 


Rahul Tandon

516-627-8993 Xtn 208

[EMAIL PROTECTED] blocked::mailto:[EMAIL PROTECTED] 

 


FleXTrade Systems Inc.

111 Great Neck Rd.,Suite #314

Great Neck, NY 11021

This communication is for informational purposes only. The contents of this
transmission are confidential and are intended solely for the use of the
individual or entity to whom they are addressed.If you have received this
email in error please notify the sender by return email and delete this
message from your system. Flextrade Systems Inc., its subsidiaries and
affiliates do not guarantee the completeness and accuracy of this
transmission's contents. Moreover, Flextrade Systems Inc., its subsidiaries
and affiliates do not guarantee this communication to be free of viruses and
accept no liability for any damage caused thereof.

 



  



No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 3/19/2007 
11:49 AM
  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError

2007-03-20 Thread Filip Hanik - Dev Lists


addendum to my previous post,

Unable to create new native thread errors can also depend on heap 
fragmentation, since thread stacks are in the process heap, there might 
not be enough continuous space there.


Filip

Rahul Tandon wrote:

Hi All,

 


If I don't give -Xmx option in CATALINA_OPTS, then it hangs and Catalina.out
has following error message:

 

 


java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)

at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

Caused by: java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:574)

at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.init(ThreadPool.
java:643)

at
org.apache.tomcat.util.threads.ThreadPool.openThreads(ThreadPool.java:515)

at
org.apache.tomcat.util.threads.ThreadPool.start(ThreadPool.java:148)

at
org.apache.tomcat.util.net.PoolTcpEndpoint.startEndpoint(PoolTcpEndpoint.jav
a:315)

at
org.apache.coyote.http11.Http11BaseProtocol.start(Http11BaseProtocol.java:15
0)

at
org.apache.coyote.http11.Http11Protocol.start(Http11Protocol.java:75)

at
org.apache.catalina.connector.Connector.start(Connector.java:1089)

at
org.apache.catalina.core.StandardService.start(StandardService.java:459)

at
org.apache.catalina.core.StandardServer.start(StandardServer.java:709)

at org.apache.catalina.startup.Catalina.start(Catalina.java:551)

... 6 more

 

 


Any clue?

 

 


Thanks,

 


Rahul Tandon

516-627-8993 Xtn 208

[EMAIL PROTECTED] blocked::mailto:[EMAIL PROTECTED] 

 


FleXTrade Systems Inc.

111 Great Neck Rd.,Suite #314

Great Neck, NY 11021

This communication is for informational purposes only. The contents of this
transmission are confidential and are intended solely for the use of the
individual or entity to whom they are addressed.If you have received this
email in error please notify the sender by return email and delete this
message from your system. Flextrade Systems Inc., its subsidiaries and
affiliates do not guarantee the completeness and accuracy of this
transmission's contents. Moreover, Flextrade Systems Inc., its subsidiaries
and affiliates do not guarantee this communication to be free of viruses and
accept no liability for any damage caused thereof.

 



  



No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.14/727 - Release Date: 3/19/2007 
11:49 AM
  



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-16 Thread Rahul Tandon

Thanks Kevan.

I tried changing stack size (ulimit -s 8192) to 8 MB and thought it should
sovle the problem, but it did not..rather it gave error:
Previous stack size was 10240 kbytes when the application works with
-Xmx704m
Any more thoughts?

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xbf0bd45e, pid=11734, tid=16384
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# 
[error occurred during error reporting, step 60, id 0xb]

# An error report file with more information is saved as hs_err_pid11734.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xbefbd45e, pid=11821, tid=16384
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# 
[error occurred during error reporting, step 60, id 0xb]

# An error report file with more information is saved as hs_err_pid11821.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp

 

Rahul Tandon



-Original Message-
From: Kevan Miller [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 15, 2007 10:05 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError


Rahul,
There's an inverse relationship between your maximum heap size and  
the number of threads that can be allocated within your process. Your  
OS (and Java) will allocate memory for each Thread you create. By  
increasing your max heap, you're actually reducing the amount of  
memory available for thread creation.

--kevan

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-15 Thread Rahul Tandon

Any clue?

Thanks,

 

Rahul Tandon

516-627-8993 Xtn 208

[EMAIL PROTECTED]

 

111 Great Neck Rd.,Suite #314

Great Neck, NY 11021

This communication is for informational purposes only. The contents of this
transmission are confidential and are intended solely for the use of the
individual or entity to whom they are addressed.If you have received this
email in error please notify the sender by return email and delete this
message from your system. Flextrade Systems Inc., its subsidiaries and
affiliates do not guarantee the completeness and accuracy of this
transmission's contents. Moreover, Flextrade Systems Inc., its subsidiaries
and affiliates do not guarantee this communication to be free of viruses and
accept no liability for any damage caused thereof.


-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 12:09 PM
To: Tomcat Users List
Subject: RE: OutOfMemoryError

 From: Rahul Tandon [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError
 
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75

Doesn't seem excessive.  What does ulimit say about your user process
virtual memory limit?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError

2007-03-15 Thread Kevan Miller



Rahul,
There's an inverse relationship between your maximum heap size and  
the number of threads that can be allocated within your process. Your  
OS (and Java) will allocate memory for each Thread you create. By  
increasing your max heap, you're actually reducing the amount of  
memory available for thread creation.


--kevan

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-14 Thread Caldarale, Charles R

 From: Rahul Tandon [mailto:[EMAIL PROTECTED] 
 Subject: OutOfMemoryError

 Caused by: java.lang.OutOfMemoryError: unable to create new 
 native thread

 I am checking vmstat at this time and see 3GB free memory.

You appear to have hit a limitiation on the number of threads you can
create within your user process space; you have not run out of JVM heap.
(Note that this has nothing to do with the amount of RAM on your system
or how much of it is in use.)  By increasing the portion of user process
space reserved for the JVM heap, you are reducing the amount left over
for other things, such as threads and file descriptors.  How many
threads have you configured for the Tomcat connectors?

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-14 Thread Rahul Tandon

I am using:

maxThreads=150 minSpareThreads=25 maxSpareThreads=75


Thanks,

Rahul Tandon

[EMAIL PROTECTED]



-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 11:52 AM
To: Tomcat Users List
Subject: RE: OutOfMemoryError

 From: Rahul Tandon [mailto:[EMAIL PROTECTED] 
 Subject: OutOfMemoryError
 
 Caused by: java.lang.OutOfMemoryError: unable to create new 
 native thread
 
 I am checking vmstat at this time and see 3GB free memory.

You appear to have hit a limitiation on the number of threads you can
create within your user process space; you have not run out of JVM heap.
(Note that this has nothing to do with the amount of RAM on your system
or how much of it is in use.)  By increasing the portion of user process
space reserved for the JVM heap, you are reducing the amount left over
for other things, such as threads and file descriptors.  How many
threads have you configured for the Tomcat connectors?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-14 Thread Caldarale, Charles R

 From: Rahul Tandon [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError

 maxThreads=150 minSpareThreads=25 maxSpareThreads=75

Doesn't seem excessive.  What does ulimit say about your user process
virtual memory limit?

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError

2007-03-14 Thread Rahul Tandon

I have following output for ulimit -a

core file size(blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size   (kbytes, -m) unlimited
open files(-n) 1024
pipe size  (512 bytes, -p) 8
stack size(kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes(-u) 7168
virtual memory(kbytes, -v) unlimited



Thanks,

 

Rahul Tandon

516-627-8993 Xtn 208

[EMAIL PROTECTED]

 

111 Great Neck Rd.,Suite #314

Great Neck, NY 11021

This communication is for informational purposes only. The contents of this
transmission are confidential and are intended solely for the use of the
individual or entity to whom they are addressed.If you have received this
email in error please notify the sender by return email and delete this
message from your system. Flextrade Systems Inc., its subsidiaries and
affiliates do not guarantee the completeness and accuracy of this
transmission's contents. Moreover, Flextrade Systems Inc., its subsidiaries
and affiliates do not guarantee this communication to be free of viruses and
accept no liability for any damage caused thereof.


-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 14, 2007 12:09 PM
To: Tomcat Users List
Subject: RE: OutOfMemoryError

 From: Rahul Tandon [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError
 
 maxThreads=150 minSpareThreads=25 maxSpareThreads=75

Doesn't seem excessive.  What does ulimit say about your user process
virtual memory limit?

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-19 Thread Ronald Klop


It helped us to upgrade to java 1.5.0_10. There are fixes for memory leaks in 
native memory. They do not show up in the java heap.

Ronald.

On Wed Feb 07 23:34:45 CET 2007 Tomcat Users List users@tomcat.apache.org 
wrote:


---
Version Information:

---
Red Hat Linux: 2.4.21-4.ELsmp #1 SMP i686 i686 i386 GNU/Linux
Apache: 2.0.54
mod_jk: 1.2.20
tomcat: 4.1.34
java: 1.5.0_06 (build 1.5.0_06-b05)



---
Problem description:

---

Under heavy load, after running for some time, some tomcat instances throw
OutOfMemoryErrors and then become unresponsive. 


Using jmap -heap just after such an error occurs reports plenty of available
memory. Watching the heap before the tomcats get into this type of
situation reveals no telltale growth in memory usage.

We currently have Xmx set to 256M, we have tried increasing and decreasing
this value and there is no change in the behavior.

Questions: 
Is it possible that the initial OutOfMemory error occurs when a
large 
garbage collection is taking place and an OutOfMemoryError is thrown


before the memory can be reclaimed throwing the whole system into
some
sort of bad state? If so, how do we combat this behavior?

Is one of the tomcat threads running out of memory, and killing
itself,
thus freeing the memory? If this is what is happening, does anyone
have 
any advice on catching the tomcat memory usage just prior to going
into 
a bad state?



Based on other's reports of similar problems we have investigated a number
of system resources and their limits (file descriptors, threads, etc) with
no luck. (below are some statistics that seem to show that these other
areas are not the problem).

One perhaps telling piece of information is that once a tomcat has gotten
into this state, we find that many connections to apache end up in the
SYN_RECV state (as reported by netstat). It appears that tomcat's listener
thread is still accepting connections, but something goes wrong in the
handoff to the processor threads such that the connection is left in
SYN_RECV. This is curious as a stack trace of tomcat's threads report many
(20+) processor threads in await() waiting for the next thing to process.

I have included as much relevant information as I can think of below, but am
happy to provide additional information should anyone have any ideas as to
what may be going wrong.


We would be very thankful to hear from anyone who may have any experience of
similar problems, or guidance with what to try as next steps.



---
Version Information:

---
Red Hat Linux: 2.4.21-4.ELsmp #1 SMP i686 i686 i386 GNU/Linux
Apache: 2.0.54
mod_jk: 1.2.20
tomcat: 4.1.34
java: 1.5.0_06 (build 1.5.0_06-b05)


---
System setup:

---

We are running apache to serve static content, and mod_jk with balanced
workers to forward requests for dynamic content to 5 tomcat instances. The
following are the relevant settings:


Apache settings (httpd.conf):

Timeout 300
KeepAlive On
MaxKeepAliveRequests 100

IfModule prefork.c
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 200
MaxRequestsPerChild 100
/IfModule



mod_jk settings (worker.properties)

worker.list=loadbalancer

worker.tomcat1.port=11009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.socket_timeout=30
worker.tomcat1.reply_timeout=6
worker.tomcat1.connection_pool_size=1
worker.tomcat1.connection_pool_minsize=1
worker.tomcat1.connection_pool_timeout=300
worker.tomcat1.lbfactor=1
worker.tomcat1.recover_time=600

### (same settings for tomcat2 - tomcat5) ###

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers= tomcat1, tomcat2, tomcat3,
tomcat4, tomcat5


tomcat settings (server.xml)

Connector className=org.apache.ajp.tomcat4.Ajp13Connector
port=11009 minProcessors=5 maxProcessors=100
acceptCount=10 debug=0 enableLookups=false/




After running for some time (anywhere from 20 minutes to 12 hours depending
on load), we see one instance of tomcat stop responding. The following are
the errors reported in vairous logs.


---
catalina.out error messages (stderr/stdout from catalina.sh):

---

2007-02-07 12:43:22 Ajp13Processor[15009][3] 
process: invoke java.lang.OutOfMemoryError: Java heap space

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-09 Thread Tim Funk


http://tomcat.apache.org/faq/memory.html

If you have a lot of servlets or JSP's, you may need to increase your 
permanent generation. By default, it is 64MB. Doubling it to be 
-XX:MaxPermSize=256m might be a good start.


Pardon the bad math in the faq since 64*2!=256 ;)


-Tim

Nikola Milutinovic wrote:

PS Perm Generation
   capacity = 22675456 (21.625MB)
   used = 22515408 (21.472366333007812MB)
   free = 160048 (0.1526336669921875MB)
   99.2941795746026% used


Here is the failure. PermGen is getting exhausted.



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-09 Thread Nelson, Tracy M.

| From: Tim Funk [mailto:[EMAIL PROTECTED]
| Sent: Friday, 09 February, 2007 06:30
| 
| Pardon the bad math in the faq since 64*2!=256 ;)

Obviously you were thinking 64  2 -- happens to everybody... ;)

-

The information contained in this message is confidential
proprietary property of Nelnet, Inc. and its affiliated 
companies (Nelnet) and is intended for the recipient only.
Any reproduction, forwarding, or copying without the express
permission of Nelnet is strictly prohibited. If you have
received this communication in error, please notify us
immediately by replying to this e-mail.



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-08 Thread Nikola Milutinovic

 You have quite a bit of memory in your 'Old Generation'.  You need to
 determine what you're allocating that isn't being released.

Not true, see below.

  Heap Usage:
  PS Young Generation
  Eden Space:
 capacity = 10223616 (9.75MB)
 used = 4748760 (4.528770446777344MB)
 free = 5474856 (5.221229553222656MB)
 46.44892765925481% used

This is OK.

  From Space:
 capacity = 524288 (0.5MB)
 used = 483360 (0.460968017578125MB)
 free = 40928 (0.039031982421875MB)
 92.193603515625% used

Also normal.

  To Space:
 capacity = 9109504 (8.6875MB)
 used = 0 (0.0MB)
 free = 9109504 (8.6875MB)
 0.0% used

This is always 0, AFAIK.

  PS Old Generation
 capacity = 238616576 (227.5625MB)
 used = 162772160 (155.23162841796875MB)
 free = 75844416 (72.33087158203125MB)
 68.21494245227959% used

This is also NOT the cause of problems.

  PS Perm Generation
 capacity = 22675456 (21.625MB)
 used = 22515408 (21.472366333007812MB)
 free = 160048 (0.1526336669921875MB)
 99.2941795746026% used

Here is the failure. PermGen is getting exhausted.

Nix.




 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-08 Thread Sharon French



Given this information at the top of the jmap -heap output:

Heap Configuration:
...
   PermSize = 16777216 (16.0MB)
   MaxPermSize  = 67108864 (64.0MB)

Doesn't this mean that I can grow to 64M of PermGen space?

I do see the capacity of PermGen increase over time (with analogous
increases in the used field).

I'm wondering if I may be running into an OutOfMemoryError because I've run
out of available PermGen space, requiring changes to the heap generation
partitions and this re-partitioning requires so much time/effort that the
ergonomics factor is kicking in (as explained in section 5.2.2 of
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.0.Ergonomics%2
0in%20the%20throughput%20collector%7Coutline)?


However, the error message I am getting is: java.lang.OutOfMemoryError:
Java heap space rather than a perm space message.

Can this message be trusted? Or could this be a PermGen issue?

Thank you for your help,

Sharon French






-Original Message-
From: Nikola Milutinovic [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 08, 2007 5:05 PM
To: Tomcat Users List
Subject: Re: OutOfMemoryError (but not really out of memory?) cause tomcat
processes to hang


  PS Perm Generation
 capacity = 22675456 (21.625MB)
 used = 22515408 (21.472366333007812MB)
 free = 160048 (0.1526336669921875MB)
 99.2941795746026% used

Here is the failure. PermGen is getting exhausted.

Nix.




 


Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-08 Thread Caldarale, Charles R

 From: Sharon French [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError (but not really out of memory?) 
 cause tomcat processes to hang

 Given this information at the top of the jmap -heap output:
   Heap Configuration:
   ...
  PermSize = 16777216 (16.0MB)
  MaxPermSize  = 67108864 (64.0MB)
 Doesn't this mean that I can grow to 64M of PermGen space?

In theory, yes.  In practice, the GC may not be able to move the
boundary between the OldGen and the PermGen.  It tries to balance usage
of each of the generations, and doesn't always get it right.

 I do see the capacity of PermGen increase over time (with analogous
 increases in the used field).

More classes are being loaded the longer you run.

 I'm wondering if I may be running into an OutOfMemoryError 
 because I've run out of available PermGen space,

That's what we've been trying to tell you...

 this re-partitioning requires so much time/effort that the
 ergonomics factor is kicking in (as explained in section 5.2.2 of
 http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.
 0.Ergonomics%20in%20the%20throughput%20collector%7Coutline)?

Unless you've forced -server mode, I would be a bit surprised if the JVM
chose to run that way with such a small heap.  It's unlikely you're
using the throughput collector.

 However, the error message I am getting is: 
 java.lang.OutOfMemoryError:
 Java heap space rather than a perm space message.

The PermGen is part of the Java heap.  As suggested yesterday, use
-XX:PermSize as well as -XX:MaxPermSize to insure that the PermGen has
adequate reserve.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-07 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sharon,

Sharon French wrote:
 Is it possible that the initial OutOfMemory error occurs when a large
 garbage collection is taking place and an OutOfMemoryError is thrown
 before the memory can be reclaimed

Yes. In fact, this is often when OOMs occur, since the JVM is trying
hard to avoid the OOM in the first place.

 throwing the whole system into
 some sort of bad state?

After an OOM is thrown, the JVM is basically completely hosed.

 If so, how do we combat this behavior?

Fix resource leaks, allocate an appropriate amount of memory, and limit
resource use to avoid OOMs in the first place.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFylVl9CaO5/Lv0PARAm/9AJ44AJe4/kUr/nLl9v+g92UbRlQ4HQCcD9YM
QEiVxUfHWvr5WV/LBY9jO2o=
=f9jZ
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-07 Thread John Hayward


Sharon,

You have quite a bit of memory in your 'Old Generation'.  You need to
determine what you're allocating that isn't being released.

How many sessions do you have active when the problem occurs?  What is your
session timeout?
What are you putting into your sessions (how much is held by each)?

Are you using any caching technologies like ehCache or hibernate caching?
not allowing caches to expire can eat up memory in the Old Generation space.

We use a product called LambdaProbe to monitor our tomcat instances.  It's
very helpful to count sessions, see what's in them, and to watch the memory
and requests in real-time.

If you really *need* everything you're storing and you don't have any low
hanging fruit, you may just need to run with more memory.  If you could test
such a configuration you may find that the memory utilization stabilizes at
an acceptable level.

-John

On 2/7/07, Sharon French [EMAIL PROTECTED] wrote:




---
  Version Information:


---
Red Hat Linux:   2.4.21-4.ELsmp #1 SMP i686 i686 i386 GNU/Linux
   Apache:   2.0.54
   mod_jk:   1.2.20
   tomcat:   4.1.34
 java:   1.5.0_06 (build 1.5.0_06-b05)




---
  Problem description:


---

Under heavy load, after running for some time, some tomcat instances throw
OutOfMemoryErrors and then become unresponsive.

Using jmap -heap just after such an error occurs reports plenty of
available
memory.  Watching the heap before the tomcats get into this type of
situation  reveals no telltale growth in memory usage.

We currently have Xmx set to 256M, we have tried increasing and decreasing
this value and there is no change in the behavior.

Questions:
Is it possible that the initial OutOfMemory error occurs when a
large
garbage collection is taking place and an OutOfMemoryError is
thrown

before the memory can be reclaimed throwing the whole system into
some
sort of bad state? If so, how do we combat this behavior?

Is one of the tomcat threads running out of memory, and killing
itself,
thus freeing the memory? If this is what is happening, does anyone
have
any advice on catching the tomcat memory usage just prior to going
into
a bad state?


Based on other's reports of similar problems we have investigated a number
of system resources and their limits (file descriptors, threads, etc) with
no luck.  (below are some statistics that seem to show that these other
areas are not the  problem).

One perhaps telling piece of information is that once a tomcat has gotten
into this state, we find that many connections to apache end up in the
SYN_RECV state  (as reported by netstat).  It appears that tomcat's
listener
thread is still  accepting connections, but something goes wrong in the
handoff to the processor threads such that the connection is left in
SYN_RECV.  This is curious as a  stack trace of tomcat's threads report
many
(20+) processor threads in await() waiting for the next thing to process.

I have included as much relevant information as I can think of below, but
am
happy to  provide additional information should anyone have any ideas as
to
what may be  going wrong.


We would be very thankful to hear from anyone who may have any experience
of
similar problems, or guidance with what to try as next steps.




---
  Version Information:


---
Red Hat Linux:   2.4.21-4.ELsmp #1 SMP i686 i686 i386 GNU/Linux
   Apache:   2.0.54
   mod_jk:   1.2.20
   tomcat:   4.1.34
 java:   1.5.0_06 (build 1.5.0_06-b05)



---
  System setup:


---

We are running apache to serve static content, and mod_jk with balanced
workers to forward requests for dynamic content to 5 tomcat
instances.  The
following  are the relevant settings:


  Apache settings (httpd.conf):

Timeout 300
KeepAlive On
MaxKeepAliveRequests 100

   IfModule prefork.c
   StartServers 5
   MinSpareServers  5
   MaxSpareServers 10
   MaxClients 200
   MaxRequestsPerChild  100
/IfModule



  mod_jk settings (worker.properties)

worker.list=loadbalancer

worker.tomcat1.port=11009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.socket_timeout=30
worker.tomcat1.reply_timeout=6

RE: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang


 You have quite a bit of memory in your 'Old Generation'.  You need to
determine 
 what you're allocating that isn't being released.

We have a fairly substantial amount of data that is loaded on startup and
remains for the duration.  This probably accounts for part of the old-gen
usage.

I also see that this number increases _and_ decreases over time.  My
understanding is that this indicates that we have some long-lived objects,
but when a full-gc is forced they get cleaned up as well.  Am I
understanding this correctly?

 How many sessions do you have active when the problem occurs?  

I'm not sure - what is the best way to find this out? 

 What is your session timeout? 

The default of 30 minutes.

 What are you putting into your sessions (how much is held by each)?

Very little - a handful (~5) smallish (100 char) strings.

 Are you using any caching technologies like ehCache or hibernate caching? 
 not allowing caches to expire can eat up memory in the Old Generation
space.

Nope.

 We use a product called LambdaProbe to monitor our tomcat instances.  
 It's very helpful to count sessions, see what's in them, and to watch 
 the memory and requests in real-time.

I will check this out. Thanks for the suggestion.

 If you really *need* everything you're storing and you don't have any 
 low hanging fruit, you may just need to run with more memory.  If you 
 could test such a configuration you may find that the memory utilization 
 stabilizes at an acceptable level.

This is part of my confusion, turning the Xmx value up seems to have no
effect on the problem.  A while back I did a bunch of investigation with
gclogging and each tomcat instance seemed to level off it's usage at around
120M.  

So my guess is that we are not dealing with a standard growing of objects
over time, but perhaps a case of something going awry that throws us into
the OutOfMemory case.  But I'm struggling with how to catch that something.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang

2007-02-07 Thread Leon Rosenberg


Hello Sharon,

just some thoughts

On 2/7/07, Sharon French [EMAIL PROTECTED] wrote:


---
  Version Information:

---
Red Hat Linux:   2.4.21-4.ELsmp #1 SMP i686 i686 i386 GNU/Linux
   Apache:   2.0.54
   mod_jk:   1.2.20
   tomcat:   4.1.34
 java:   1.5.0_06 (build 1.5.0_06-b05)



apart from the problem, pretty old setup :-)



We currently have Xmx set to 256M, we have tried increasing and decreasing
this value and there is no change in the behavior.


I assume the Xms value is set to the same value as Xmx? If not, at
least earlier jdks tendered to through outofmemory during heap resize.

Do you have a graph on memory consumption (System.freeMemory()) ? If
yes, is it linear?

The changes in Xmx values, did they had any impact on the duration of
the servers good state under load?



Questions:
Is it possible that the initial OutOfMemory error occurs when a
large
garbage collection is taking place and an OutOfMemoryError is thrown

before the memory can be reclaimed throwing the whole system into
some
sort of bad state?


yes.


If so, how do we combat this behavior?


Give the system enough memory. Enough means, that it always have
enough to serve the requests during a gc run. You should study your
memory consumption (for example with System.freeMemory output or
something) and configure your memory values to be sufficent. I don't
know which treshhold is suitable for you, I prefer to have at least
100MB in the VM just in case :-).



Is one of the tomcat threads running out of memory, and killing
itself,
thus freeing the memory? If this is what is happening, does anyone
have
any advice on catching the tomcat memory usage just prior to going
into
a bad state?


You could try some gc options. How much memory does your machine have?
I also assume you run 32 bit?




Based on other's reports of similar problems we have investigated a number
of system resources and their limits (file descriptors, threads, etc) with
no luck.  (below are some statistics that seem to show that these other
areas are not the  problem).


Hmm, call me silly, but I would increase PermGen space too. just in case.


We are running apache to serve static content, and mod_jk with balanced
workers to forward requests for dynamic content to 5 tomcat instances.  The
following  are the relevant settings:


Your instances are all on the same machine? Why?
Btw, can you reproduce the error in testing environment? Could it be
that you simply have a memory leak?

regards
Leon

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

 From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
 Subject: Re: OutOfMemoryError (but not really out of memory?) 
 cause tomcatprocesses to hang

 Sharon French wrote:
  Is it possible that the initial OutOfMemory error occurs 
  when a large garbage collection is taking place and an
  OutOfMemoryError is thrown before the memory can be reclaimed

 Yes. In fact, this is often when OOMs occur, since the JVM is trying
 hard to avoid the OOM in the first place.

Uhhh - no.  The JVM will not return an OOME until the GC is completely
finished and the request still cannot be satisfied.  Even with
concurrent GC, failing allocation requests are suspended until a full GC
has completed.  The exception to the above is if a request is made that
could never be satisfied; that will be given an OOME immediately.

 After an OOM is thrown, the JVM is basically completely hosed.

Definitely not true.  The JVM is still functional, although the app
(Tomcat, in this case) may not be able to proceed.

  If so, how do we combat this behavior?

 Fix resource leaks, allocate an appropriate amount of memory, 
 and limit resource use to avoid OOMs in the first place.

Very good advice.  If you can, use a profiler to find out what (and who)
is consuming the heap.  However, the 64m given to the PermGen is rather
small for an app server, given the number of classes that must be
loaded; for that matter, the 256m for the whole heap is pretty tiny
these days.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang


 Uhhh - no.  The JVM will not return an OOME until the GC 
 is completely finished and the request still cannot be 
 satisfied.  Even with concurrent GC, failing allocation 
 requests are suspended until a full GC has completed.  
 The exception to the above is if a request is made that 
 could never be satisfied; that will be given an OOME 
 immediately.

This is very helpful to know.  So if after receiving such OOMEs, I run jmap
-heap and there is plenty of memory, I'm assuming that whomever was sucking
up the memory has either given it back or died off - right?

(The dying off would line up with fact that the number of processors tomcat
says he's started is less than the number of threads I currently see
running.)

Now it's down to how do I catch the culprit? 

Since I don't see steady memory growth, I believe that there must be some
error condition that is handled improperly that throws us into some sort of
memory cosumption craziness.  Since by the time the symptom is present,
there is plenty of memory available, I'm having trouble catching the case.
Any suggestions?

 After an OOM is thrown, the JVM is basically completely hosed.

 Definitely not true.  The JVM is still functional, although the app 
 (Tomcat, in this case) may not be able to proceed.

This also lines up with my observations. The first several OOMEs don't seem
to trip us up, however at some point we hit a threshold that does hose us.

Given that after such an error occurs, we have plently of memory, and plenty
of threads sitting in await(), any ideas on why the connections to apache
end up in SYN_RECV? Am I right in thinking that this indicates that the
tomcat listener thread has accepted the connection but then fails to pass it
off to a processor thread to handle?  Or does the pass off happen but for
some reason the socket is hosed?  Any thoughts here?


  If so, how do we combat this behavior?
 
 Fix resource leaks, allocate an appropriate amount of memory,
 and limit resource use to avoid OOMs in the first place.

 However, the 64m given to the PermGen is rather small for an app server.

We don't seem to ever get to a usage of  20M for PermGen, and the
OutOfMemoryErrors always indicate java heap space.  Is this error message
reliable? Can I count on the fact that it's really heap space I'm out of
(I've seen reports of this indicating other problems, but all seem to be
pre-1.5 jvm).

Thanks for the help thus far!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcat processes to hang


 I assume the Xms value is set to the same value as Xmx? 
 If not, at least earlier jdks tendered to through outofmemory 
 during heap resize.

I will give this a shot. Thanks.

 The changes in Xmx values, did they had any impact on the duration 
 of the servers good state under load?

Nope.  This (along with the lack of memory growth over time) leads me to
believe that it's not a normal memory leak, but more a poorly handled error
case somewhere that sends us into a tailspin which eventually results in the
OOME.  (I've done a good bit of monitoring of the heap and things grow and
shrink over time, and then seemingly out of the blue we'll see an OOME.)


 How much memory does your machine have? 

4G (currently each of the 5 tomcats has Xmx=256M, apache runs on the same
machine)

 I also assume you run 32 bit?

yes

 Your instances are all on the same machine? Why?

Because that's the machine that we've got available right now ;)


 Btw, can you reproduce the error in testing environment? 
 Could it be that you simply have a memory leak?

For all my efforts I cannot reproduce the error on a staging machine. Though
I wish I could...


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

 From: Sharon French [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError (but not really out of memory?) 
 cause tomcatprocesses to hang

 I'm assuming that whomever was sucking up the memory has
 either given it back or died off - right?

Not necessarily.  The OOME could have been presented due to an
unreasonably large request that could never be satisifed.  The memory
won't be given back until another GC has run, although minor GCs run
quite frequently in a HotSpot JVM.

 Now it's down to how do I catch the culprit? 

The first step is to turn on -verbose:gc so you can get a better idea of
what's happening when.  You might want to update the JVM to the current
1.5.0_11 level, just to make sure it's not some sort of heap management
problem in your relatively old level.

You should have stack traces to go with the OOME reports; where do these
show the execution to be?

 Given that after such an error occurs, we have plently 
 of memory, and plenty of threads sitting in await(),
 any ideas on why the connections to apache end up in
 SYN_RECV?

Sorry, I have no experience with httpd.

 the OutOfMemoryErrors always indicate java heap space.
 Is this error message reliable?

It should be in 1.5; 1.4 gave no clue as to the actual underlying
clause.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

2007-02-07 Thread John Hayward


We've seen errors where individual queries are improperly bounded or
unbounded allowing requests to attempt to retrieve unreasonable amounts of
data.  A single request like this can take an otherwise stable system and
throw it into all sorts of bad behaviors and error conditions.

To assist with this debugging you may try to run your jvm with gc logging
turned on, and log the http requests coming in.  If you then have an OOM
crash you can correlate the spike in memory allocation (on a timeline) with
certain requests that may have caused it.

you can use tools like gcviewer to post-process your gc log files to see
what was going on with your memory over time.

-John

On 2/7/07, Sharon French [EMAIL PROTECTED] wrote:



 Uhhh - no.  The JVM will not return an OOME until the GC
 is completely finished and the request still cannot be
 satisfied.  Even with concurrent GC, failing allocation
 requests are suspended until a full GC has completed.
 The exception to the above is if a request is made that
 could never be satisfied; that will be given an OOME
 immediately.

This is very helpful to know.  So if after receiving such OOMEs, I run
jmap
-heap and there is plenty of memory, I'm assuming that whomever was
sucking
up the memory has either given it back or died off - right?

(The dying off would line up with fact that the number of processors
tomcat
says he's started is less than the number of threads I currently see
running.)

Now it's down to how do I catch the culprit?

Since I don't see steady memory growth, I believe that there must be some
error condition that is handled improperly that throws us into some sort
of
memory cosumption craziness.  Since by the time the symptom is present,
there is plenty of memory available, I'm having trouble catching the case.
Any suggestions?

 After an OOM is thrown, the JVM is basically completely hosed.

 Definitely not true.  The JVM is still functional, although the app
 (Tomcat, in this case) may not be able to proceed.

This also lines up with my observations. The first several OOMEs don't
seem
to trip us up, however at some point we hit a threshold that does hose us.

Given that after such an error occurs, we have plently of memory, and
plenty
of threads sitting in await(), any ideas on why the connections to apache
end up in SYN_RECV? Am I right in thinking that this indicates that the
tomcat listener thread has accepted the connection but then fails to pass
it
off to a processor thread to handle?  Or does the pass off happen but for
some reason the socket is hosed?  Any thoughts here?


  If so, how do we combat this behavior?

 Fix resource leaks, allocate an appropriate amount of memory,
 and limit resource use to avoid OOMs in the first place.

 However, the 64m given to the PermGen is rather small for an app server.

We don't seem to ever get to a usage of  20M for PermGen, and the
OutOfMemoryErrors always indicate java heap space.  Is this error
message
reliable? Can I count on the fact that it's really heap space I'm out of
(I've seen reports of this indicating other problems, but all seem to be
pre-1.5 jvm).

Thanks for the help thus far!

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
John Hayward

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

 You should have stack traces to go with the OOME reports; where do these
show the execution to be?

Nope - no stack trace :(.  
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4753347 seems to indicate
that this was missed in the 1.5.0 release and came in with 1.5.1.


 It should be in 1.5; 1.4 gave no clue as to the actual underlying clause.

Again, thanks for the info.



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

 From: Sharon French [mailto:[EMAIL PROTECTED] 
 Subject: RE: OutOfMemoryError (but not really out of memory?) 
 cause tomcatprocesses to hang

 Nope - no stack trace :(.  
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4753347 
 seems to indicate that this was missed in the 1.5.0 release
 and came in with 1.5.1.

Even the bug report is out of date - 1.5.1 was cancelled quite a while
ago, in order to concentrate on stabilizing Java SE 6.  Since that's now
recently released, you could try that, if you're really gutsy...

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: OutOfMemoryError (but not really out of memory?) cause tomcatprocesses to hang

2007-02-07 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
 In fact, this is often when OOMs occur, since the JVM is trying
 hard to avoid the OOM in the first place.
 
 Uhhh - no.  The JVM will not return an OOME until the GC is completely
 finished and the request still cannot be satisfied

The collector itself requires the creation of Java objects on the heap.
If the collector does not have enough memory to do the collection, it
can easily barf.

 After an OOM is thrown, the JVM is basically completely hosed.
 
 Definitely not true.  The JVM is still functional, although the app
 (Tomcat, in this case) may not be able to proceed.

Fair enough. But if Tomcat isn't happy, nobody's happy ;)

 However, the 64m given to the PermGen is rather small for an app
 server

It's clear from the OP's heap stats that the Perm space is busting. Odd,
though: the MaxPermSpace is 64MB, but she is topping out at 20MB or so.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFym3I9CaO5/Lv0PARAo5MAJ9pBpTS+bi8FIl0UPm/I3IJAxi1WQCdFAWN
PbonyKzrLbbTfztMBXyxX1A=
=IkDu
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: OutOfMemoryError (but not really out of memory?) cause tomcatprocessesto hang