[keycloak-user] KEYCLOAK-3202 Creating users causes memory leak

Valerij Timofeev valerij.timofeev at gmail.com
Mon Jul 11 05:08:20 EDT 2016

Thank you for the prompt response Stian.

> adding an eviction policy to the realmVersions cache.

This was my impression after reading the ticket too, but I was not sure,
because according pull request looks a little bit more complicated.
We will give a try to this Keycloak setting in the production environment
We are going to enable Infinispan statistics additionally to get more

> Is there any errors in the logs?

We could identify only errors duiring the service logout until now:

Stack Trace:





sun.reflect.GeneratedMethodAccessor10512.invoke(Unknown Source)


> What is the status code returned with the empty page?

Our web application unfortunately does not log status code and error
message. Exception message is null in case of service account logout. We
will roll out a fix for this with the next web application release on
Thursday this week.

Additionally we are going to switch from the OIDC logout endpint method to
the ServletRequest.logout() method because it seems to be a more consistent
way for a web application which is already protected by Keycloak EAP 6
adapters, isn't it?

Additional details about the experienced behaviour: the empty page is our
web application internal page. In Google Chrome webbrowser I see for
example that the initiator of the last POST request to this internal page
was www.googletagmanager.com/gtm.js?id=... Could be this a problem?
If I refresh this empty page, I'm back in the web application (still logged
But if I call OCID logout endpoint
(/realms/${realm}/protocol/openid-connect/logout) in the same browser
myself  and then refresh the empty page, then I'm redirected to the KC
login screen.

Any ideas?

Apart from that I hope that we will get more information after the release
on Thursday.

2016-07-11 7:37 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> Hi,
> You can relatively easily try though by adding an eviction policy to the
> realmVersions cache. I found that with roughly a million users there would
> be around 500Mb of memory consumed, which will run you into issues with the
> default settings if you have that many users login over a space of a day
> and a half.
> Empty page could be due to timeout. Is there any errors in the logs? What
> is the status code returned with the empty page?
> On 8 July 2016 at 10:40, Valerij Timofeev <valerij.timofeev at gmail.com>
> wrote:
>> Hi Stian,
>> You are the assignee in KEYCLOAK-3202
>> <https://issues.jboss.org/browse/KEYCLOAK-3202>, so I addressed this
>> email to you directly.
>> I guess that this issue could be the cause of trouble in our production
>> environment.
>> There are 4 EAP-6 nodes with Keycloak adapters and 2 Keycloak 1.9.4
>> standalone servers running in 2 clusters respectively.
>> We experience logout failures approximately after one and a half days of
>> operation.
>> Restarting EAP 6 nodes temporary resolves the logout problem.
>> Durable load tests in out test environment showed that login and logout
>> of existing users don't result in above behaviour.
>> We added to the durable load test additional scenario creating new users
>> and were able to reproduce logout failure: users are getting empty page and
>> not the login screen as expected. Page reload navigates back into the
>> protected web application .
>> Logout is accomplished in a Java web applictaion by calling OIDC logout
>> endpoint:
>> *FacesContext                .getCurrentInstance()
>> .getExternalContext()
>> .redirect(keycloakDeployment.getLogoutUrl().queryParam("redirect_uri",
>> redirectURL).toTemplate());*
>> Logout is initiated via h:commandLink, so I suppose that the OIDC logout
>> endpoint is called via the GET method. Should we use the POST method
>> instead?
>> Has servlet logout any advantages?
>> *((HttpServletRequest)
>> FacesContext.getCurrentInstance().getExternalContext().getRequest()).logout();*
>> I'd appreciate quick response*, *because restarting production EAP
>> cluster every day is not a pleasant option ;-)
>> Thank you in advance
>> Kind regards
>> Valerij Timofeev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160711/066bef48/attachment.html 

More information about the keycloak-user mailing list