Again, I'm not entirely sure, but I've found some hints that for basic-auth
strategy, we don't want the servlet container to create any HttpSession objects
at all. So a possible fix would be to tell Shiro not to create a HttpSession
object, whenever we are using basic-auth strategy.
I'm working on this ...
// Basic auth should never create sessions ...
request.setAttribute("org.apache.shiro.subject.support.DefaultSubjectContext.SESSION_CREATION_ENABLED",
Boolean.FALSE);
On 2019/08/03 12:52:49, Andi Huber <[email protected]> wrote:
> I think I tracked down the reason why these PrincipalForApplicationUser
> instances won't get garbage collected:
>
> With Basic-Auth as the authentication strategy, each request to the REST
> endpoint spawns a new HTTP Session, which holds a reference to a collection
> of PrincipalForApplicationUser instances.
>
> Now when tomcat runs in a mode, where it keeps all the sessions (session
> persistence mode) these objects cannot be garbage collected.
>
> I'm not a 100% sure but, it seems the described behavior is as it should be
> and hence a non-issue.
>
> However, I'm currently investigating, whether I got it all wrong, or there is
> a convenient solution to this, eg. don't create that many HTTP session
> objects.
>
> Let me know what you think!
>
> Cheers, Andi
>
> On 2019/07/23 07:29:26, Leandro D'Agostino <L.D'[email protected]> wrote:
> > Thanks Andi!
> >
> > We look forward to your findings.
> >
> > Leandro
> >
> > On 7/23/19 9:11 AM, Andi Huber wrote:
> > > We will certainly investigate this.
> > >
> > > Thanks for the effort of tracking this down!
> > >
> > > I've opened a Jira ticket [1].
> > >
> > > KR Andi
> > >
> > > [1] https://issues.apache.org/jira/browse/ISIS-2156
> > >
> > > On 2019/07/22 14:30:44, Leandro D'Agostino <L.D'[email protected]> wrote:
> > >> Hi,
> > >>
> > >> We ran into the issue that our application keeps building up memory but
> > >> never releases it.
> > >> We could track it down to the class PrincipalForApplicationUser. Every
> > >> time a user is authenticated, a new PrincipalForApplicationUser object
> > >> is created and it is then never released. We experience this memory
> > >> issue after a change of increasing the number of permissions from 20 to
> > >> about 200. When comparing the behaviour of the application before and
> > >> after the change we see that the retained size of the
> > >> PrincipalForApplicationUser class has increased from about 15KB per
> > >> instance to about 210KB per instance.
> > >>
> > >> For our investigation we created a test environment based on the
> > >> simpleapp application to be able to isolate the issue and reproduce the
> > >> issue in a minimalistic environment. So the simpleapp application was
> > >> extended with 200 fields on which permissions are set. In our test we
> > >> set the maximum memory size of the VM to 200MB. The test application
> > >> uses about 40MB initially. We then start firing requests to the
> > >> application (using jmeter), to:
> > >> /restful/services/simple.SimpleObjectMenu
> > >> What we observe then is that memory usage grows rather quickly and
> > >> eventually it is exhausted.
> > >>
> > >> Can you help with a solution for this issue?
> > >>
> > >> The simpleapp test application we used is available on github:
> > >> https://github.com/pocos-nl/isis-simpleapp-memoryissues
> > >>
> > >> It also includes the jmeter test script:
> > >> memoryLeak-bareApp-SecurityPerformanceTestObject.jmx
> > >>
> > >> Thanks,
> > >> Leandro D'Agostino
> > >>
> > >>
> > >>
> >
>
