Morten, David, I think this is a bug. I opened https://issues.apache.org/jira/browse/GERONIMO-5800 to track progress on it.
As a temporary workaround (that I haven't tested for breaking other stuff) as the last thing in your servlet you should be able to call Subject subject = ContextManager.getCurrentCaller(); ContextManager.unregisterSubject(subject); which will remove the identity hash map entry. Many thanks for identifying this problem! Actual fixes will probably be somewhat different in 2.1 and 2.2 but I expect the above workaround should work for either. Only use it for basic auth though -- it will probably really break form auth. thanks david jencks On Feb 8, 2011, at 11:54 AM, Morten Svanæs wrote: > Hi David! > > Ok, thanks for the clarification regarding http sessions, sorry for > the maybe strange question I'm quite new to Geronimo and ejb security. > The "server" is a servlet using stateless ejb's. The servlet is > configured to use http basic as authentication method, we have our own > login module based on GenericSecurityRealm and SQLLoginModule. > > I'm using a java test client that makes many small http requests > requests to the server. > The test client is only connecting as one user. > > The strange memory behavior is only seen after I run the program for a > while ( I'm running the java program in bash while loop making about > 500 small http requests :) > When I inspect the heap dump on start when the client only has run to > or three times everything seems fine, it's only after 20-50 iterations > I clearly see that the ContextManger.IdentityHashMap related objects > dominate and seems to slowly grow. > > When I comment out all security in the web.xml the memory usage stays > totally stable for many hundred iterations and there is no sign of the > ContextManager objects. > > To me it seems like something don't get cleaned up properly. > Is there something a need to do make sure the requests get cleaned up > after they has been used maybe? > > > Regards > Morten > > > > > > On Tue, Feb 8, 2011 at 6:23 PM, David Jencks <david_jen...@yahoo.com> wrote: >> Hi Morten, >> >> I'm not sure why this is happening, it might be a bug. Just to be sure we >> investigate the right context, is this >> >> - a servlet >> - a pojo web service (if so, jaxrpc, jaxws, or something else) >> - an ejb web service? >> >> The ContextManager doesn't have anything to do with http sessions, it is >> more concerned with keeping the user identity in a threadlocal during each >> request so it is always available for authorization decisions. >> >> Thanks for your investigations so far! >> >> david jencks >> >> On Feb 8, 2011, at 4:51 AM, Morten Svanæs wrote: >> >>> Hi, >>> I'm currently having memory problems with a stateless web service >>> running in Geronimo 2.2.1. >>> The problem is that after running for a while the server starts >>> consuming more and more memory, some kind of leak or accumulation of >>> unwanted objects occur. >>> After analyzing the heap dumps in mat I can clearly see that the >>> accumulation happens inside the >>> org.apache.geronimo.security.ContextManagers's subjectContexts >>> IdentityHashMap. >>> The login happens via http basic and a custom LoginModule looking up >>> users in the database. The login module is based on the >>> GenericSecurityRealm and SQLLoginModule. >>> The service is a standard web servlet running on jetty. The service is >>> called typically many hundred times a second by the client with stand >>> http basic auth urls, so there is actually no need for sessions at >>> all. >>> It seems like when users log on to the service the >>> credentials/siubject gets stuck in the subjectContexts hashmap even >>> though the session timeout is set for 1 sec in the web.xml file. >>> >>> I've disabled session cookies by using information found here: >>> http://www.mojavelinux.com/blog/archives/2006/11/disabling_session_cookies_in_jetty/ >>> >>> I assume this is some kind of misconfiguration on our side and not the >>> stand. behavior with Geronimo, anyone who can help us point out the >>> direction for solving this would be greatly appreciated. >>> >>> >>> Regards, >>> Netroms Nacoma >> >> > > > > -- > > > > Mvh. > Morten Svanæs > Mobil: 40478335
