geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Workaround to Subject memory leak (GERINOMO-5800)
Date Thu, 01 Sep 2011 15:59:59 GMT
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
> 
> 
> 


Mime
View raw message