You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by df...@teamhuber.com on 2011/09/01 16:18:53 UTC

Workaround to Subject memory leak (GERINOMO-5800)

I am attempting to find a solid workaround for the memory leak of Subjects, which is bug GERONIMO-5800.

Background:

We have a JSF 1.2/Facelets web application, which uses FORM authentication with a SQL Database security realm.

We logout users using a Filter, and so whenever a specific 'logout.faces' page is called, we do a simple invalidate of the session:

HttpSession session = httpServletRequest.getSession(false);
if (session != null) {
session.invalidate();
}

Workaround Attempts:

I tried adding the code suggested by David Jencks like this:

HttpSession session = httpServletRequest.getSession(false);

if (session != null) {

session.invalidate();


}
Subject subject = ContextManager.getCurrentCaller();
ContextManager.unregisterSubject(subject);


That code ran without errors, but afterwards it caused EJB JNDI lookup errors on subsequent pages.

Instead of unregistering the Subject, I can change it to simply ContextManager.clearCallers() and that runs without any errors at all.  I'm just not sure if that will resolve the memory leak issue.

Questions:

1. Does anyone know if simply calling clearCallers() should address the memory leak issue.
2. Does anyone have any ideas on what else I should try?  I'm willing to change any part of our design in order to address this problem.  Currently, we are restarting our server weekly to avoid out of memory errors.

Thank you for any consideration you can provide.

David Frahm
Huber & Associates
Office: 573-634-5000, Mobile: 573-298-1040



Re: Workaround to Subject memory leak (GERINOMO-5800)

Posted by David Frahm <DF...@teamhuber.com>.
See below a sample stacktrace, which we would receive for the first user
after login and upon accessing a page which utilized @EJB.

I was running this locally in eclipse.  Also interesting was that after I
would get this exception, I couldn't re-publish.  Attempting to publish
would result in JNDI errors also.  I had to shutdown the server, start the
server, then publish, each time I wanted to test a change.

2011-08-31 14:54:42,900 ERROR [_ErrorPageWriter] An exception occurred
javax.faces.FacesException: Exception while calling encodeEnd on component :
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/jsf/orderEntryKioskPreCheck.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: bodyForm][Class:
javax.faces.component.html.HtmlOutputText,Id: j_id20]}
	at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:627)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:261)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:257)
	at javax.faces.component.UIComponent.encodeAll(UIComponent.java:257)
	at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:592)
	at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
	at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at
com.teamhuber.infomate.security.SessionControlFilter.doFilter(SessionControlFilter.java:72)
	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:191)
	at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:51)
	at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
	at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:406)
	at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
	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.valves.AccessLogValve.invoke(AccessLogValve.java:567)
	at
org.apache.geronimo.tomcat.valve.ThreadCleanerValve.invoke(ThreadCleanerValve.java:40)
	at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
	at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
	at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
	at java.lang.Thread.run(Thread.java:735)
Caused by: 
javax.faces.FacesException: Could not retrieve value of component with path
: {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/jsf/orderEntryKioskPreCheck.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: bodyForm][Class:
javax.faces.component.html.HtmlOutputText,Id: j_id20]}
	at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue(RendererUtils.java:331)
	at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:279)
	at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput(HtmlTextRendererBase.java:74)
	at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd(HtmlTextRendererBase.java:61)
	at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:624)
	... 28 more
Caused by: 
javax.faces.FacesException: java.lang.InstantiationException: Some objects
to be injected were not found in jndi: [javax.naming.NamingException: Could
not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/bankServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/salesServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/orderServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/productServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/fileMaintenanceServices
[Root exception is java.lang.NullPointerException],
javax.naming.NamingException: Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/offenderServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/applicationServices
[Root exception is java.lang.NullPointerException]]
	at
org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:155)
	at
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:198)
	at
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:164)
	at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
	at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
	at
org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:64)
	at
org.apache.myfaces.el.convert.VariableResolverToELResolver.getValue(VariableResolverToELResolver.java:95)
	at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
	at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140)
	at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:61)
	at org.apache.el.parser.AstValue.getValue(AstValue.java:107)
	at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
	at
com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
	at javax.faces.component.UIOutput.getValue(UIOutput.java:73)
	at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue(RendererUtils.java:327)
	... 32 more
Caused by: 
java.lang.InstantiationException: Some objects to be injected were not found
in jndi: [javax.naming.NamingException: Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/bankServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/salesServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/orderServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/productServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/fileMaintenanceServices
[Root exception is java.lang.NullPointerException],
javax.naming.NamingException: Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/offenderServices [Root
exception is java.lang.NullPointerException], javax.naming.NamingException:
Could not look up :
env/com.teamhuber.oe.backingbeans.OrderEntryKioskBean/applicationServices
[Root exception is java.lang.NullPointerException]]
	at org.apache.geronimo.j2ee.annotation.Holder.newInstance(Holder.java:171)
	at
org.apache.geronimo.myfaces.LifecycleProviderGBean.newInstance(LifecycleProviderGBean.java:62)
	at
org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:84)
	... 46 more

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Workaround-to-Subject-memory-leak-GERINOMO-5800-tp3301421p3321047.html
Sent from the Users mailing list archive at Nabble.com.

Re: Workaround to Subject memory leak (GERINOMO-5800)

Posted by David Jencks <da...@yahoo.com>.
Hi David,

On Sep 1, 2011, at 7:18 AM, DFrahm@teamhuber.com wrote:

> I am attempting to find a solid workaround for the memory leak of Subjects, which is bug GERONIMO-5800.
> 
> Background:
> 
> We have a JSF 1.2/Facelets web application, which uses FORM authentication with a SQL Database security realm.
> 
> We logout users using a Filter, and so whenever a specific 'logout.faces' page is called, we do a simple invalidate of the session:
> 
> HttpSession session = httpServletRequest.getSession(false);
> if (session != null) {
> session.invalidate();
> }
> 
> Workaround Attempts:
> 
> I tried adding the code suggested by David Jencks like this:
> 
> HttpSession session = httpServletRequest.getSession(false);
> if (session != null) {
> session.invalidate();
> }
> Subject subject = ContextManager.getCurrentCaller();
> ContextManager.unregisterSubject(subject);
> 
> That code ran without errors, but afterwards it caused EJB JNDI lookup errors on subsequent pages.

That seems very odd to me.  Can you provide more details?  maybe a stack trace and a little bit of code context for the lookup?  If we actually fixed this in the jaspic code that's pretty much exactly what we'd do.
> 
> Instead of unregistering the Subject, I can change it to simply ContextManager.clearCallers() and that runs without any errors at all.  I'm just not sure if that will resolve the memory leak issue.
> 
> Questions:
> 
> 1. Does anyone know if simply calling clearCallers() should address the memory leak issue.

I don't think this would affect the memory leak.  Something equivalent to clearCallers() should already be happening as the request returns.

> 2. Does anyone have any ideas on what else I should try?  I'm willing to change any part of our design in order to address this problem.  Currently, we are restarting our server weekly to avoid out of memory errors.

I'd like to understand the problem you are seeing with the code I suggested since I think any fix would basically be the same as the suggestion.


thanks
david jencks

> 
> Thank you for any consideration you can provide.
> 
> David Frahm
> Huber & Associates
> Office: 573-634-5000, Mobile: 573-298-1040
> 
> 
>