Thanks so much for your attention.
We do use form authorization. However, I was thinking your fix might work in a servlet Filter doInvalidateSession() method?
Huber & Associates
Office: 573-634-5000, Mobile: 573-298-1040
-----David Jencks <email@example.com> wrote: -----
From: David Jencks <firstname.lastname@example.org>
Date: 02/08/2011 04:01PM
Subject: Re: Stateless/sessionless servlet consuming too much memory
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();
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.
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?
> On Tue, Feb 8, 2011 at 6:23 PM, David Jencks <email@example.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:
>>> 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
>>> 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
>>> 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:
>>> 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.
>>> Netroms Nacoma
> Morten Svanęs
> Mobil: 40478335