You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Kanchana Welagedara <ka...@gmail.com> on 2007/11/12 10:17:47 UTC
PermGen Out of memory exception
Hi All
I have developed 4 war files using Appfuse frame work.These war files
are independent.when I deployed any three war files the applications
are up and run.But when I deployed the 4th one (any) it throws a
PermGen exception.It has been copied in the bellow
1.Is this some thing related not setting the JAVA_OPTS ? or some security issue?
Can any body please Help me to revolve this problem.
Thanks
Kanchana
{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
{\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\f0\fs20 INFO:
XML validation disabled\par
AbandonedObjectPool is used
(org.apache.commons.dbcp.AbandonedObjectPool@81ca25)\par
\par
LogAbandoned: false\par
RemoveAbandoned: true\par
RemoveAbandonedTimeout: 60\par
AbandonedObjectPool is used
(org.apache.commons.dbcp.AbandonedObjectPool@15b9f9a\par
)\par
LogAbandoned: false\par
RemoveAbandoned: true\par
RemoveAbandonedTimeout: 60\par
AbandonedObjectPool is used
(org.apache.commons.dbcp.AbandonedObjectPool@f73893)\par
\par
LogAbandoned: false\par
RemoveAbandoned: true\par
RemoveAbandonedTimeout: 60\par
Nov 12, 2007 11:42:36 AM org.apache.catalina.core.StandardContext
resourcesStart\par
\par
SEVERE: Error starting static Resources\par
java.lang.IllegalArgumentException: Document base
C:\\Tomcat-5.5.20\\webapps\\spike\par
flow does not exist or is not a readable directory\par
at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.\par
java:140)\par
at org.apache.catalina.core.StandardContext.resourcesStart(StandardConte\par
xt.java:3848)\par
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4\par
019)\par
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)\par
\par
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)\par
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)\par
\par
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442\par
)\par
at org.apache.catalina.core.StandardService.start(StandardService.java:4\par
50)\par
at org.apache.catalina.core.StandardServer.start(StandardServer.java:709\par
)\par
at org.apache.catalina.startup.Catalina.start(Catalina.java:551)\par
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\par
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.\par
java:39)\par
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces\par
sorImpl.java:25)\par
at java.lang.reflect.Method.invoke(Method.java:585)\par
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)\par
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)\par
Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
SEVERE: Error in resourceStart()\par
Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
SEVERE: Error getConfigured\par
Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
SEVERE: Context [/spikeflow] startup failed due to previous errors\par
Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext stop\par
INFO: Container
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/\par
spikeflow] has not been started\par
AbandonedObjectPool is used
(org.apache.commons.dbcp.AbandonedObjectPool@1b7aa8)\par
\par
LogAbandoned: false\par
RemoveAbandoned: true\par
RemoveAbandonedTimeout: 60\par
Nov 12, 2007 11:43:26 AM org.apache.coyote.http11.Http11BaseProtocol start\par
INFO: Starting Coyote HTTP/1.1 on http-8282\par
Nov 12, 2007 11:43:27 AM org.apache.jk.common.ChannelSocket init\par
INFO: JK: ajp13 listening on /0.0.0.0:8009\par
Nov 12, 2007 11:43:27 AM org.apache.jk.server.JkMain start\par
INFO: Jk running ID=0 time=0/62 config=null\par
Nov 12, 2007 11:43:27 AM org.apache.catalina.storeconfig.StoreLoader load\par
INFO: Find registry server-registry.xml at classpath resource\par
Nov 12, 2007 11:43:27 AM org.apache.catalina.startup.Catalina start\par
INFO: Server startup in 176718 ms\par
[TiphAdmin] ERROR [http-8282-Processor25]
ClickstreamListener.sessionDestroyed(6\par
0) |\par
java.lang.NullPointerException\par
at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
ckstreamListener.java:55)\par
at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
va:687)\par
at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
ava:579)\par
at org.apache.catalina.connector.Request.doGetSession(Request.java:2200)\par
\par
at org.apache.catalina.connector.Request.getSession(Request.java:2024)\par
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.\par
java:831)\par
at org.springframework.web.context.request.ServletRequestAttributes.<ini\par
t>(ServletRequestAttributes.java:81)\par
at org.springframework.web.context.request.RequestContextListener.reques\par
tInitialized(RequestContextListener.java:63)\par
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV\par
alve.java:167)\par
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j\par
ava:126)\par
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j\par
ava:105)\par
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal\par
ve.java:107)\par
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav\par
a:148)\par
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java\par
:869)\par
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p\par
rocessConnection(Http11BaseProtocol.java:664)\par
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo\par
int.java:527)\par
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol\par
lowerWorkerThread.java:80)\par
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP\par
ool.java:684)\par
at java.lang.Thread.run(Thread.java:595)\par
[TiphAdmin] ERROR [http-8282-Processor23] [jsp].invoke(704) |
Servlet.service()\par
for servlet jsp threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor23] [dispatcher].invoke(704) |
Servlet.ser\par
vice() for servlet dispatcher threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor23] [default].invoke(253) |
Servlet.servic\par
e() for servlet default threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[Tiph IMS] ERROR
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] Clicks\par
treamListener.sessionDestroyed(60) |\par
java.lang.NullPointerException\par
at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
ckstreamListener.java:55)\par
at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
va:687)\par
at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
ava:579)\par
at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.ja\par
va:678)\par
at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase\par
.java:663)\par
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBas\par
e.java:1284)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1569)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1578)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1578)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.r\par
un(ContainerBase.java:1558)\par
at java.lang.Thread.run(Thread.java:595)\par
[Tiph LGS] ERROR
[ContainerBackgroundProcessor[StandardEngine[Catalina]]] Clicks\par
treamListener.sessionDestroyed(60) |\par
java.lang.NullPointerException\par
at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
ckstreamListener.java:55)\par
at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
va:687)\par
at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
ava:579)\par
at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.ja\par
va:678)\par
at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase\par
.java:663)\par
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBas\par
e.java:1284)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1569)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1578)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
rocessChildren(ContainerBase.java:1578)\par
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.r\par
un(ContainerBase.java:1558)\par
at java.lang.Thread.run(Thread.java:595)\par
[TiphAdmin] ERROR [http-8282-Processor23] [jsp].invoke(704) |
Servlet.service()\par
for servlet jsp threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor23] [dispatcher].invoke(704) |
Servlet.ser\par
vice() for servlet dispatcher threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor23] [default].invoke(253) |
Servlet.servic\par
e() for servlet default threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor25] [jsp].invoke(704) |
Servlet.service()\par
for servlet jsp threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor25] [dispatcher].invoke(704) |
Servlet.ser\par
vice() for servlet dispatcher threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
[TiphAdmin] ERROR [http-8282-Processor25] [default].invoke(253) |
Servlet.servic\par
e() for servlet default threw exception\par
java.lang.OutOfMemoryError: PermGen space\par
Exception in thread "http-8282-Processor21"
java.lang.OutOfMemoryError: PermGen\par
space\par
Exception in thread "http-8282-Processor23"
java.lang.OutOfMemoryError: PermGen\par
space\par
Exception in thread
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" jav\par
a.lang.OutOfMemoryError: PermGen space\par
\par
}
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen Out of memory exception
Posted by Peter Crowther <Pe...@melandra.com>.
> From: Jim [mailto:openbip@gmail.com]
> PermGen space, on the other hand, doesn't get garbage
> collected, so you
> need to ensure you're allocating enough to handle all that your
> application will need. Unfortunately with the web application
> classloader-system, every time you deploy an application without
> restarting the application server, more PermGen space is eaten up, and
> this is never recovered (not even if you undeploy an application).
Not entirely true. Modern Java virtual machines perform garbage collection on PermGen, but it's remarkably easy to leave a reference lying around that will hold a class in memory - which holds the class' ClassLoader in memory, which holds all the other classes loaded by that ClassLoader in memory. Unless you have unusually good hygiene rules as you develop, this makes it look like PermGen never gets garbage collected!
There's plenty of past discussion on the list on this topic; I've no doubt Chuck will reply, but I suggest http://tomcat.apache.org/faq/memory.html as a good place to start reading.
It may not be your webapp's code that's at fault, by the way. There are plenty of third party libraries that don't clean up after themselves properly (including some I've written, I'm ashamed to admit).
- Peter
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen Out of memory exception
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jim [mailto:openbip@gmail.com]
> Subject: Re: PermGen Out of memory exception
>
> The problem with that language is it implies that PermGen space is
> generally only an issue if you're using a lot of servlets or JSPs.
Agreed, that's not inclusive enough.
> there's nothing in the FAQ linking the PermGen error to the
> "Your classloaders are not being garbage collected" link.
Yes, that should be clearer.
(Poking around, I can't find any doc on how to update the FAQ - it
doesn't appear to be in the source tree, but I might have missed it.)
In any event, if you have suggested wording updates, please submit them
via Bugzilla.
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen Out of memory exception
Posted by Jim <op...@gmail.com>.
Caldarale, Charles R wrote:
>> Perhaps the Tomcat FAQ on memory-issues could be fleshed
>> out/updated?
>>
>
> This specific item is already in the Tomcat FAQ:
> "If you have a lot of servlets or JSP's, you may need to increase your
> permanent generation. By default, it is 64MB. Doubling [sic] it to be
> -XX:MaxPermSize=256m might be a good start."
>
The problem with that language is it implies that PermGen space is
generally only an issue if you're using a lot of servlets or JSPs. But
these days, I assume more people are getting PermGen issues not with
servlets/JSPs but with framework stacks -- e.g. Hibernate makes hungry
use of PermGen. Further, this entry implies that an application will
take a static amount of PermGen, so doubling it will solve the problem,
but I read about a lot of people having this issue on reload/redeploy --
i.e. the classloader leak, but there's nothing in the FAQ linking the
PermGen error to the "Your classloaders are not being garbage collected"
link. I agree with you that that article has pretty much everything,
but it's put at the end of the list almost as an afterthought, and I'd
also suggest that if someone had already concluded that their
classloaders were not being garbage collected, they'd have already found
that link. We should put some <marquee> and <blink> tags around it! : )
Mostly I'm just being defensive, but I do truly appreciate the correction.
Jim
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen Out of memory exception
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jim [mailto:openbip@gmail.com]
> Subject: Re: PermGen Out of memory exception
>
> To address your rhetorical question :) , this issue is a
> mess to research.
Which is why it should be done before deployment...
> it can be intimidating to be pointed at a 21 page
> Sun white paper
Try this one first:
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
Unfortunately, it does not address class-heavy situations, such as app
servers.
> http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang,
> which suggests upgrading Tomcat, or switching to JRockit, or
> upgrading the JVM.
Switching to JRockit only masks the problem temporarily, since it
doesn't have a separate space for instances of java.lang.Class; do
enough app reloads with JRockit, and you will run into the problem.
We've also found other significant issues with JRockit, so I can't
recommend it.
> http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back
This one article is the source of much misinformation. It's unfortunate
that the author has decided his conclusions are the only possible ones
that explain the symptoms, regardless of reality.
> The fallacy's just not obvious, and there's no simple authority
> on this common issue.
Well, actually there is - look at the HotSpot JVM code, which is freely
available. Of course, there are side effects ("My brain hurts!" "It
will have to come out." :-).
> Perhaps the Tomcat FAQ on memory-issues could be fleshed
> out/updated?
This specific item is already in the Tomcat FAQ:
"If you have a lot of servlets or JSP's, you may need to increase your
permanent generation. By default, it is 64MB. Doubling [sic] it to be
-XX:MaxPermSize=256m might be a good start."
> an explicit contrary statement in the FAQ would be helpful
This article linked to from "Your classloaders are not being garbage
collected" seems to cover pretty much everything you've asked for. For
reference, it points to the following location:
http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action
?pageId=2669
- 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen Out of memory exception
Posted by Jim <op...@gmail.com>.
Caldarale, Charles R wrote:
>> From: Jim [mailto:openbip@gmail.com]
>> Subject: Re: PermGen Out of memory exception
>>
>> PermGen space, on the other hand, doesn't get garbage collected
>>
>
> As Peter C indicated, this is utter BS. Why do people keep propagating
> this fallacy? Easier to blame the JVM than take responsibility for bugs
> in your own code?
>
Cool, thanks a lot for the clarification, and sorry about that. So
there's nothing in the JVM or Tomcat (possible unknown/unfixed bugs
notwithstanding) that precludes PermGen space from being recovered via
garbage collection when undeploying an application? It's necessarily a
leak in the application or one of the libraries/frameworks it uses?
To address your rhetorical question :) , this issue is a mess to
research. This industry being what it is, it can be intimidating to be
pointed at a 21 page Sun white paper when users are screaming because
the application is down; it certainly makes it hard for me to defend the
learning curve of using Java-based open source approaches when that's
the suggested avenue. People are obviously going to look for the quick
answers first: Tomcat's FAQ (http://tomcat.apache.org/faq/memory.html)
suggests too many servlets/JSPs for the PermGen issue. I use frameworks
rather than servlets/JSPs directly, but when I go to the forums/bugs for
those frameworks, they're usually blaming each other, or Tomcat, or the
JVM. Turning, then, to a couple examples from Google:
- Google "tomcat permgen" and get
http://www.jroller.com/agileanswers/entry/preventing_java_s_java_lang,
which suggests upgrading Tomcat, or switching to JRockit, or upgrading
the JVM.
- Google "permgen error", and get
http://my.opera.com/karmazilla/blog/2007/03/15/permgen-strikes-back,
which says: "And finally, the permanent generation. This is for objects
that the virtual machine has decided to endorse with eternal life -
which is precicely the core of the problem. Objects in the permanent
generation are never garbage collected; that is, under /normal/
circumstances when the jvm is started with /normal/ command line
parameters."
It's hard not to take that last snippet at face value, for example, when
a blank application with a framework stack leaks on reload, and all said
frameworks claim to be leak-free. It's also called /Perm/Gen. The
fallacy's just not obvious, and there's no simple authority on this
common issue.
Perhaps the Tomcat FAQ on memory-issues could be fleshed out/updated?
With so many blogs, forum posts, and bug-report-discussion-threads
suggesting that it's normal to expect an unbounded PermGen increase when
reloading/redeploying applications, an explicit contrary statement in
the FAQ would be helpful, if even to clarify for users that yes, they
/should/ bother doing their own memory-profiling on this issue, because
there /is/ a problem with some code they're using, whether it's theirs
or another party's. The PermGen discussion in the FAQ should be
expanded to include the now-common case of PermGen running out not
because of servlets/JSPs but because of Hibernate's heavy PermGen usage,
or because some other third party is precluding classloader garbage
collection on reload/redeploy (which would be a great place for the link
to Spring's compilation of leak issues with third-party libraries).
Jim
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: PermGen Out of memory exception
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jim [mailto:openbip@gmail.com]
> Subject: Re: PermGen Out of memory exception
>
> PermGen space, on the other hand, doesn't get garbage collected
As Peter C indicated, this is utter BS. Why do people keep propagating
this fallacy? Easier to blame the JVM than take responsibility for bugs
in your own code?
> By default (at least, if you're using Sun Java), a Java process
> is given 32Mb of "PermGen" memory. If you have the "-server"
> flag set for your Java process, the default is 64Mb.
No, the default maximum is 64MB for both client and server modes, at
least in the 1.5 and 1.6 JVMs. The initial size is different for client
and server, but that's largely immaterial.
> To set the upper-bound of PermGen space, then, use the flag:
> "-XX:MaxPermSize=#m".
This is most likely all that's needed, since there does not appear to be
any redeployment involved. There are simply too many classes defined
for the default PermGen size.
Here's a good starting point for descriptions of GC and heap operations:
http://java.sun.com/javase/technologies/hotspot/gc/index.jsp
Setting -Dcom.sun.management.jmxremote and running JConsole with Tomcat
can provide useful information about what's going on with JVM 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 start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: PermGen Out of memory exception
Posted by Jim <op...@gmail.com>.
Hi Kanchana,
Java processes use two types of memory: the "heap" (which is garbage
collected), and "PermGen" memory (which is not garbage collected).
Generally speaking, you won't run out of heap memory unless your
application is set up so that the memory for all the objects being used
at a single moment (and thus, which can't be garbage collected) is
greater than the heap space. In this case, you would only increase the
amount of heap memory associated with a process to lower the frequency
at which the application needs to run the garbage-collection process
(the tradeoff: when the garbage collector /does/ run, it'll take
longer). You can change the maximum heap-size for a process by adding
the "-Xmx #m" flag to your "java" command. e.g. "java MyApplication
-Xmx128m"
PermGen space, on the other hand, doesn't get garbage collected, so you
need to ensure you're allocating enough to handle all that your
application will need. Unfortunately with the web application
classloader-system, every time you deploy an application without
restarting the application server, more PermGen space is eaten up, and
this is never recovered (not even if you undeploy an application). By
default (at least, if you're using Sun Java), a Java process is given
32Mb of "PermGen" memory. If you have the "-server" flag set for your
Java process, the default is 64Mb. I found that my mid-sized
Hibernate/Spring/Tapestry application would eat up ~8Mb of PermGen
memory every deploy; so increasing this memory to 128M+ will directly
influence the number of deploys you can do before you'll have problems.
To set the upper-bound of PermGen space, then, use the flag:
"-XX:MaxPermSize=#m". By the way, to add these flags, if you're using
startup.bat on Windows you can add 'SET JAVA_OPTS=%JAVA_OPTS% -server
-...' lines to the top of it to append flags to your JAVA_OPTS variable
before the server is started using those flags. If you're on *nix, you
can add 'export JAVA_OPTS="$JAVA_OPTS -server -...."' lines to your
startup.sh.
Note that you can simply restart your application server to clear out
all PermGen memory that was used with applications that you've
undeployed. So, I'd use a memory profiler (I used YourKit) to see how
much PermGen space is used by your application each deploy, and set your
PermGen space high enough to cover all of your different apps
side-by-side, plus some extra memory to handle the number of hot-deploys
you expect yourself having to make at some point -- and then just
remember to restart the server when you can after a hot-deploy or two.
Jim
Kanchana Welagedara wrote:
> Hi All
>
>
> I have developed 4 war files using Appfuse frame work.These war files
> are independent.when I deployed any three war files the applications
> are up and run.But when I deployed the 4th one (any) it throws a
> PermGen exception.It has been copied in the bellow
>
> 1.Is this some thing related not setting the JAVA_OPTS ? or some security issue?
>
> Can any body please Help me to revolve this problem.
>
> Thanks
> Kanchana
>
>
> {\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fswiss\fcharset0 Arial;}}
> {\*\generator Msftedit 5.41.21.2500;}\viewkind4\uc1\pard\f0\fs20 INFO:
> XML validation disabled\par
> AbandonedObjectPool is used
> (org.apache.commons.dbcp.AbandonedObjectPool@81ca25)\par
> \par
> LogAbandoned: false\par
> RemoveAbandoned: true\par
> RemoveAbandonedTimeout: 60\par
> AbandonedObjectPool is used
> (org.apache.commons.dbcp.AbandonedObjectPool@15b9f9a\par
> )\par
> LogAbandoned: false\par
> RemoveAbandoned: true\par
> RemoveAbandonedTimeout: 60\par
> AbandonedObjectPool is used
> (org.apache.commons.dbcp.AbandonedObjectPool@f73893)\par
> \par
> LogAbandoned: false\par
> RemoveAbandoned: true\par
> RemoveAbandonedTimeout: 60\par
> Nov 12, 2007 11:42:36 AM org.apache.catalina.core.StandardContext
> resourcesStart\par
> \par
> SEVERE: Error starting static Resources\par
> java.lang.IllegalArgumentException: Document base
> C:\\Tomcat-5.5.20\\webapps\\spike\par
> flow does not exist or is not a readable directory\par
> at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.\par
> java:140)\par
> at org.apache.catalina.core.StandardContext.resourcesStart(StandardConte\par
> xt.java:3848)\par
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4\par
> 019)\par
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)\par
> \par
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)\par
> at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)\par
> \par
> at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442\par
> )\par
> at org.apache.catalina.core.StandardService.start(StandardService.java:4\par
> 50)\par
> at org.apache.catalina.core.StandardServer.start(StandardServer.java:709\par
> )\par
> at org.apache.catalina.startup.Catalina.start(Catalina.java:551)\par
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\par
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.\par
> java:39)\par
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces\par
> sorImpl.java:25)\par
> at java.lang.reflect.Method.invoke(Method.java:585)\par
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)\par
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)\par
> Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
> SEVERE: Error in resourceStart()\par
> Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
> SEVERE: Error getConfigured\par
> Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext start\par
> SEVERE: Context [/spikeflow] startup failed due to previous errors\par
> Nov 12, 2007 11:42:37 AM org.apache.catalina.core.StandardContext stop\par
> INFO: Container
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/\par
> spikeflow] has not been started\par
> AbandonedObjectPool is used
> (org.apache.commons.dbcp.AbandonedObjectPool@1b7aa8)\par
> \par
> LogAbandoned: false\par
> RemoveAbandoned: true\par
> RemoveAbandonedTimeout: 60\par
> Nov 12, 2007 11:43:26 AM org.apache.coyote.http11.Http11BaseProtocol start\par
> INFO: Starting Coyote HTTP/1.1 on http-8282\par
> Nov 12, 2007 11:43:27 AM org.apache.jk.common.ChannelSocket init\par
> INFO: JK: ajp13 listening on /0.0.0.0:8009\par
> Nov 12, 2007 11:43:27 AM org.apache.jk.server.JkMain start\par
> INFO: Jk running ID=0 time=0/62 config=null\par
> Nov 12, 2007 11:43:27 AM org.apache.catalina.storeconfig.StoreLoader load\par
> INFO: Find registry server-registry.xml at classpath resource\par
> Nov 12, 2007 11:43:27 AM org.apache.catalina.startup.Catalina start\par
> INFO: Server startup in 176718 ms\par
> [TiphAdmin] ERROR [http-8282-Processor25]
> ClickstreamListener.sessionDestroyed(6\par
> 0) |\par
> java.lang.NullPointerException\par
> at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
> ckstreamListener.java:55)\par
> at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
> va:687)\par
> at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
> ava:579)\par
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2200)\par
> \par
> at org.apache.catalina.connector.Request.getSession(Request.java:2024)\par
> at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.\par
> java:831)\par
> at org.springframework.web.context.request.ServletRequestAttributes.<ini\par
> t>(ServletRequestAttributes.java:81)\par
> at org.springframework.web.context.request.RequestContextListener.reques\par
> tInitialized(RequestContextListener.java:63)\par
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV\par
> alve.java:167)\par
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j\par
> ava:126)\par
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j\par
> ava:105)\par
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal\par
> ve.java:107)\par
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav\par
> a:148)\par
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java\par
> :869)\par
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p\par
> rocessConnection(Http11BaseProtocol.java:664)\par
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo\par
> int.java:527)\par
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol\par
> lowerWorkerThread.java:80)\par
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP\par
> ool.java:684)\par
> at java.lang.Thread.run(Thread.java:595)\par
> [TiphAdmin] ERROR [http-8282-Processor23] [jsp].invoke(704) |
> Servlet.service()\par
> for servlet jsp threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor23] [dispatcher].invoke(704) |
> Servlet.ser\par
> vice() for servlet dispatcher threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor23] [default].invoke(253) |
> Servlet.servic\par
> e() for servlet default threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [Tiph IMS] ERROR
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] Clicks\par
> treamListener.sessionDestroyed(60) |\par
> java.lang.NullPointerException\par
> at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
> ckstreamListener.java:55)\par
> at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
> va:687)\par
> at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
> ava:579)\par
> at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.ja\par
> va:678)\par
> at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase\par
> .java:663)\par
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBas\par
> e.java:1284)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1569)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1578)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1578)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.r\par
> un(ContainerBase.java:1558)\par
> at java.lang.Thread.run(Thread.java:595)\par
> [Tiph LGS] ERROR
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] Clicks\par
> treamListener.sessionDestroyed(60) |\par
> java.lang.NullPointerException\par
> at com.opensymphony.clickstream.ClickstreamListener.sessionDestroyed(Cli\par
> ckstreamListener.java:55)\par
> at org.apache.catalina.session.StandardSession.expire(StandardSession.ja\par
> va:687)\par
> at org.apache.catalina.session.StandardSession.isValid(StandardSession.j\par
> ava:579)\par
> at org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.ja\par
> va:678)\par
> at org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase\par
> .java:663)\par
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBas\par
> e.java:1284)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1569)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1578)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.p\par
> rocessChildren(ContainerBase.java:1578)\par
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.r\par
> un(ContainerBase.java:1558)\par
> at java.lang.Thread.run(Thread.java:595)\par
> [TiphAdmin] ERROR [http-8282-Processor23] [jsp].invoke(704) |
> Servlet.service()\par
> for servlet jsp threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor23] [dispatcher].invoke(704) |
> Servlet.ser\par
> vice() for servlet dispatcher threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor23] [default].invoke(253) |
> Servlet.servic\par
> e() for servlet default threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor25] [jsp].invoke(704) |
> Servlet.service()\par
> for servlet jsp threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor25] [dispatcher].invoke(704) |
> Servlet.ser\par
> vice() for servlet dispatcher threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> [TiphAdmin] ERROR [http-8282-Processor25] [default].invoke(253) |
> Servlet.servic\par
> e() for servlet default threw exception\par
> java.lang.OutOfMemoryError: PermGen space\par
> Exception in thread "http-8282-Processor21"
> java.lang.OutOfMemoryError: PermGen\par
> space\par
> Exception in thread "http-8282-Processor23"
> java.lang.OutOfMemoryError: PermGen\par
> space\par
> Exception in thread
> "ContainerBackgroundProcessor[StandardEngine[Catalina]]" jav\par
> a.lang.OutOfMemoryError: PermGen space\par
> \par
> }
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org