Skip to main content

PermGen error on Glassfish v2ur1

4 replies [Last post]
j_kirby
Offline
Joined: 2008-04-13

Hi,

I'm currently developing a web application using Visual Web Pack and Toplink Essentials on Netbeans 6.1 RC1.

The application is being deployed remotely onto a Glassfish v2ur1 app server running on Debian 4.0 with JRE 6u4.

After a series of undeployment/deployments I receive the following error on the app server:

java.lang.OutOfMemoryError: PermGen space

I am currently working around the issue by increasing the maxpermsize to 256MB, but am hoping to find a more long term solution.

I saw a couple of other threads relating to this issue however they were regarding glassfish v1 and the issue appeared to have been resolved.

Has anyone else had similar issues with v2?

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cappelleh
Offline
Joined: 2007-10-11

Also check http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded and http://mediacast.sun.com/users/Frank.Kieviet/media/JavaOne07-BOF9982-Per...

[b]edit:[/b]

I have a similar problem with an application on GlassFish version: Sun Java System Application Server 9.1_02 (build b04-fcs).

From the above resources I found out how to get a memory dump and check what's left. 2 classes are suspicious (that is left in memory after undeploying webapp):

[b]class com.sun.faces.application.ConverterPropertyEditorFor_org_richfaces_model_selection_ClientSelection (84 bytes) : ??
class com.sun.faces.application.ConverterPropertyEditorFor_org_apache_myfaces_custom_fileupload_UploadedFile (84 bytes) : ??[/b]

Following strong links on both of these classes eventually brought me to an instance of:

[b]org.apache.commons.io.FileCleaningTracker$Reaper@0x1c2354b8[/b]

For that class I found this remark in the api:

[i]In an environment with multiple class loaders (a servlet container, for example), you should consider stopping the background thread if it is no longer needed. This is done by invoking the method exitWhenFinished, typically in javax.servlet.ServletContextListener#contextDestroyed or similar. [/i]

And a ticket about this problem: http://issues.apache.org/jira/browse/IO-99

It's part of the commons IO project which I'm not even using in my project. I did find this lib in the admin gui webapp shipping with glassfish: glassfish\lib\install\applications\admingui\adminGUI_war\WEB-INF\lib. It uses version 1.2.

Not sure if that really is the problem but it surely is a direction I'm looking at right now.

[b]Calling this exitWhenFinished method didn't help![/b]

[b]edit2:[/b]

Removing these 2 classes from the project, just for testing resolves the problem.

For ClientSelection I also found a ticket but that is for an application running on Tomcat: https://jira.jboss.org/jira/browse/RF-7911. The instance of ClientSelection I looked at was also linked to that FileCleainingTracker.

I created a ticket for the myfaces-tomahawk project as well: https://issues.apache.org/jira/browse/TOMAHAWK-1464

Can TS point out if he is using one of these libraries?

aperezymadrid
Offline
Joined: 2008-01-16

There is a report of that error somewhere. You have to add three lines:

-Xmx=512m
-XX:MaxPermSize=256m
-XX:PermSize=256m

or more memory if needed.

asherwin
Offline
Joined: 2008-04-15

This happens to me everyday (on Sun AppServer 9.1_01, and still on 9.1_02)

It happens when im working all day re-deploying my web app as i change thing (i can only estimate in the range of 50-100 deployments).

The deployment of the web app succeeds, its when you access the page that the out of memory error occurs. This takes so many redeployments that it only happens to me once a day during a full day of web app deployment.

My env:

NetBeans 6.1 (happened on 6.01 as well)
Sun AppServer 9.1_02 (happened on 9.1_01 as well)

NetBeans has -Xms128m and -Xmx756m (irrelevant though, Sun AppServer is being run seperate outside of the NetBeans JVM)

My domain has a max memory setting of -Xmx1024m, and never comes close to using it (small single web app running only)

I'm positive the problem is not actual memory consumption, but Glassfish must have some memory leak that builds up over time... Possibly from remote deployment of applications?

Here is the stacktrace:

java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:961)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1423)
at org.apache.jasper.compiler.JspDocumentParser.parseCustomAction(JspDocumentParser.java:1190)
at org.apache.jasper.compiler.JspDocumentParser.startElement(JspDocumentParser.java:429)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.java:203)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:208)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:124)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:184)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:409)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:542)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:474)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:366)
|#]

[#|2008-05-16T15:42:32.421-0400|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=17;_ThreadName=httpSSLWorkerThread-6080-0;_RequestID=1c1f3472-174b-4e9c-82d0-1dfd30ffc452;|WebModule[/AcadiaConduit]javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space
javax.faces.FacesException: javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:413)
at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:442)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:115)
at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:320)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
at com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.render(PartialTraversalLifecycle.java:106)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:267)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Caused by: javax.servlet.ServletException: java.lang.OutOfMemoryError: PermGen space
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:384)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:542)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:474)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:366)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:408)
... 40 more
Caused by: java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:961)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1423)
at org.apache.jasper.compiler.JspDocumentParser.parseCustomAction(JspDocumentParser.java:1190)
at org.apache.jasper.compiler.JspDocumentParser.startElement(JspDocumentParser.java:429)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:533)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:330)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:375)
at org.apache.jasper.compiler.JspDocumentParser.parse(JspDocumentParser.java:203)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:208)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:124)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:184)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:409)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:592)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:344)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:855)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:703)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:542)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:474)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:366)
|#]

Jason Lee

On Fri, May 16, 2008 at 3:01 PM, wrote:
> NetBeans has -Xms128m and -Xmx756m (irrelevant though, Sun AppServer is being run seperate outside of the NetBeans JVM)
>
> My domain has a max memory setting of -Xmx1024m, and never comes close to using it (small single web app running only)

Those affect only heap size, and not PermGen space, two completely
separate areas of memory. To change the PermGen space size, you can
up the maximum by adding this as a JVM option:

-XX:MaxPermSize=192m

If I understand things correctly, PermGen (or Permanent Generation) is
used to store metadata about classes being loaded. It gets cleaned
up, I think, but not as quickly as the heap, or so it would seem.
Increasing the size for GF instances in which a lot of redeployments
occur gives the system enough breathing room to work while it waits
for the garbage collector to kick in.

That's my semi-educated understanding of that, at any rate. :P
Regardless of how it works, it does seem to work. :)

--
Jason Lee, SCJP
Software Architect -- Objectstream, Inc.
Mojarra and Mojarra Scales Dev Team
https://mojarra.dev.java.net
https://scales.dev.java.net
http://blogs.steeplesoft.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net