Here's an exception from that day:
Apr 27, 2009 8:28:50 AM org.apache.catalina.core.StandardWrapperValve
invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at
com
.google
.inject
.util.FinalizableReferenceQueue.start(FinalizableReferenceQueue.java:59)
at
com
.google
.inject
.util
.FinalizableReferenceQueue
.createAndStart(FinalizableReferenceQueue.java:66)
at
com
.google
.inject
.util
.FinalizableReferenceQueue.<clinit>(FinalizableReferenceQueue.java:62)
at
com
.google
.inject
.util.FinalizableWeakReference.<init>(FinalizableWeakReference.java:33)
at com.google.inject.util.ReferenceMap
$WeakKeyReference.<init>(ReferenceMap.java:428)
at com.google.inject.util.ReferenceMap.referenceKey(ReferenceMap.java:
242)
at
com
.google
.inject
.util
.AbstractReferenceCache.internalCreate(AbstractReferenceCache.java:45)
at
com
.google
.inject.util.AbstractReferenceCache.get(AbstractReferenceCache.java:116)
at
com
.google
.inject.util.StackTraceElements.forMember(StackTraceElements.java:52)
at
com
.google
.inject.ProvisionException.createMessage(ProvisionException.java:35)
at
com.google.inject.ProvisionException.<init>(ProvisionException.java:29)
at com.google.inject.InjectorImpl
$SingleParameterInjector.inject(InjectorImpl.java:646)
at com.google.inject.InjectorImpl.getParameters(InjectorImpl.java:666)
at com.google.inject.InjectorImpl
$SingleMethodInjector.inject(InjectorImpl.java:575)
at com.google.inject.InjectorImpl.injectMembers(InjectorImpl.java:674)
at com.google.inject.InjectorImpl$8.call(InjectorImpl.java:682)
at com.google.inject.InjectorImpl$8.call(InjectorImpl.java:681)
at com.google.inject.InjectorImpl.callInContext(InjectorImpl.java:747)
at com.google.inject.InjectorImpl.injectMembers(InjectorImpl.java:680)
at
com
.xperts
.dashboard
.utility
.GuiceVariableResolver.resolveVariable(GuiceVariableResolver.java:29)
at
com
.sun
.faces
.el
.VariableResolverChainWrapper
.getValue(VariableResolverChainWrapper.java:107)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
com
.sun
.faces
.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:45)
at org.apache.el.parser.AstValue.getValue(AstValue.java:86)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at com.sun.facelets.el.ELText$ELTextVariable.writeText(ELText.java:184)
at
com.sun.facelets.compiler.TextInstruction.write(TextInstruction.java:45)
at
com
.sun.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:
39)
at com.sun.facelets.compiler.UILeaf.encodeAll(UILeaf.java:149)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:
577)
at
org
.ajax4jsf
.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at
org
.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:
176)
at
com
.sun
.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:
110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
290)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:
178)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at
org
.ajax4jsf
.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org
.apache
.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:
147)
at
org
.apache
.catalina
.core
.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
235)
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:
263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
844)
at org.apache.coyote.http11.Http11Protocol
$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:
447)
at java.lang.Thread.run(Unknown Source)
It didn't specify PermGen or anything, even though that seems quite
low in our QA testing.
I'd like to look at the memory utilization in production with SSL
enabled, but my business and operations counterparts don't want to
inconvenience users. And unfortunately, we're unable to replicate the
problem in QA with any sort of clue as to why it happens. As this
point, with the exact codebase running in production as HTTP without
issue, it's hard to suggest it's anything but a configuration issue in
Tomcat.
Chris Stewart
cstewart...@gmail.com
On Apr 28, 2009, at 5:38 PM, Mark Thomas wrote:
Chris Stewart wrote:
I put Lambda Probe (http://www.lambdaprobe.org/d/index.htm) on the
web
server to monitor some of the memory usage. Here's what I'm finding
after 20 minutes of running. Keep in mind this is without SSL
enabled.
Something I should have asked before - exactly what was out of
memory when you
saw the OOME?
Name Used Committed Maximum Initial Group
Tenured Gen 129.73Mb 138.86Mb 945.25Mb 118.19Mb HEAP
Perm Gen 45.88Mb 46.00Mb 64.00Mb 12.00Mb NON_HEAP
Survivor Space 957.74Kb 1.13Mb 7.88Mb 960.00Kb HEAP
Code Cache 12.19Mb 12.22Mb 32.00Mb 192.00Kb NON_HEAP
Eden Space 6.75Mb 9.38Mb 63.00Mb 7.94Mb HEAP
Total 195.48Mb 207.58Mb 1.09Gb 139.25Mb TOTAL
Everything is running fine at the moment but I'm a little concerned
about Perm Gen and the space we have allocated for it. I imagine
that
it's possible, with SSL enabled, that the space is being used up. Is
there enough overhead with SSL to have this scenario? I did some
reading on Perm Gen and we do use an extensive about of Hibernate in
this application, and it's JSF based.
You really need to look at this with SSL enabled.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
