[keycloak-user] How to enable Infinispan cache for realms, users and user sessions in Keycloak 1.6.1?

Stian Thorgersen sthorger at redhat.com
Mon Nov 30 02:38:25 EST 2015 

It is not expected behavior. Users should only be invalidated if changes
are made.

On 30 November 2015 at 07:01, Lohitha Chiranjeewa <kalc04 at gmail.com> wrote:

> Just tested the same flow extensively with Keycloak 1.2.0 as well, and it
> seems the behavior is the same. Lots of MySQL select queries getting
> executed with each call. Seems there's a number of unnecessary cache
> invalidations going on which causes Keycloak to fetch data from the DB over
> and over.
>
> Could you please confirm if this is the expected behavior? As far as I can
> see there's considerable performance degradation due to unnecessary cache
> invalidations.
>
>
> On Fri, Nov 27, 2015 at 8:42 PM, Lohitha Chiranjeewa <kalc04 at gmail.com>
> wrote:
>
>> I'm invoking the following API call: https://{host}/auth/admin/realms/xxxxx/users/55ffe851-2d94-460e-88b9-bc7340531b56
>> (same realm and user ID over and over again). The two HA server(s) are idle
>> apart from serving those calls. And I'm seeing the following SQL getting
>> logged in my MySQL log for each and every call:
>>
>> select userentity0_.ID as ID1_42_, userentity0_.CREATED_TIMESTAMP as
>> CREATED_2_42_, userentity0_.EMAIL as EMAIL3_42_,
>> userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_42_, userentity0_.EMAIL_VERIFIED
>> as EMAIL_VE5_42_, userentity0_.ENABLED as ENABLED6_42_,
>> userentity0_.federation_link as federati7_42_, userentity0_.FIRST_NAME as
>> FIRST_NA8_42_, userentity0_.LAST_NAME as LAST_NAM9_42_,
>> userentity0_.REALM_ID as REALM_I10_42_,
>> userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_42_,
>> userentity0_.TOTP as TOTP12_42_, userentity0_.USERNAME as USERNAM13_42_
>> from USER_ENTITY userentity0_ where
>> userentity0_.ID='55ffe851-2d94-460e-88b9-bc7340531b56' and
>> userentity0_.REALM_ID='xxxxx'
>>
>>
>>
>> On Fri, Nov 27, 2015 at 8:03 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Strange - what are you doing and what are the SQL queries?
>>>
>>> On 27 November 2015 at 15:23, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>> wrote:
>>>
>>>> Yes Stian, that I understand. But the problem here is even if I execute
>>>> continuous user retrieval calls (same user - no other functionality in
>>>> between), still MySQL select queries get executed for each call. So there
>>>> lies an issue isn't it?
>>>>
>>>>
>>>> On Fri, Nov 27, 2015 at 6:48 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Things are still fetched from MySQL. Realms, clients, users, etc.. are
>>>>> then kept in the cache, but if it changes it's re-loaded from MySQL. We use
>>>>> an invalidation cache, not a distributed cache.
>>>>>
>>>>> On 27 November 2015 at 14:04, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> What I mean is, if it were working, I shouldn't see mysql queries
>>>>>> getting executed right? So my guess is data is still fetched from the db
>>>>>> instead of the cache.
>>>>>> On Nov 27, 2015 5:52 PM, "Stian Thorgersen" <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Yup, so it's working now?
>>>>>>>
>>>>>>> On 27 November 2015 at 13:20, Lohitha Chiranjeewa <kalc04 at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Apologies, keycloak-server.json entries should change to:
>>>>>>>>
>>>>>>>>     "realm": {
>>>>>>>>         "provider": "jpa"
>>>>>>>>     },
>>>>>>>>
>>>>>>>>     "user": {
>>>>>>>>         "provider": "jpa"
>>>>>>>>     },
>>>>>>>>
>>>>>>>>     "userSessionPersister": {
>>>>>>>>         "provider": "jpa"
>>>>>>>>     },
>>>>>>>>
>>>>>>>> On Fri, Nov 27, 2015 at 5:49 PM, Lohitha Chiranjeewa <
>>>>>>>> kalc04 at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Stian,
>>>>>>>>>
>>>>>>>>> As per the migration guide, I should have Infinispan up and
>>>>>>>>> running for realms, users and user sessions without doing any specific
>>>>>>>>> changes. keycloak-server.json was reverted back to have the following
>>>>>>>>> entries:
>>>>>>>>> ...
>>>>>>>>>     "realm": {
>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>     },
>>>>>>>>>
>>>>>>>>>     "user": {
>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>     },
>>>>>>>>>
>>>>>>>>>     "userSessionPersister": {
>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>     },
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> In the Admin Console I have both Realm Cache and User Cache
>>>>>>>>> enables. I see certain Infinispan related logs getting logged as well.
>>>>>>>>>
>>>>>>>>> However, at the same time, I see MySQL queries getting executed
>>>>>>>>> for all user retrieval API invocations (even if the same user is retrieved
>>>>>>>>> continuously):
>>>>>>>>> ...
>>>>>>>>> select userentity0_.ID as ID1_42_, userentity0_.CREATED_TIMESTAMP
>>>>>>>>> as CREATED_2_42_, userentity0_.EMAIL as EMAIL3_42_,
>>>>>>>>> userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_42_, userentity0_.EMAIL_VERIFIED
>>>>>>>>> as EMAIL_VE5_42_, userentity0_.ENABLED as ENABLED6_42_,
>>>>>>>>> userentity0_.federation_link as federati7_42_, userentity0_.FIRST_NAME as
>>>>>>>>> FIRST_NA8_42_, userentity0_.LAST_NAME as LAST_NAM9_42_,
>>>>>>>>> userentity0_.REALM_ID as REALM_I10_42_,
>>>>>>>>> userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_42_,
>>>>>>>>> userentity0_.TOTP as TOTP12_42_, userentity0_.USERNAME as USERNAM13_42_
>>>>>>>>> from USER_ENTITY userentity0_ where
>>>>>>>>> userentity0_.ID='55ffe851-2d94-460e-88b9-bc7340531b56' and
>>>>>>>>> userentity0_.REALM_ID='xxxxx'
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> So it seems something is wrong here. Could you point out any areas
>>>>>>>>> that I could further look into?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Lohitha.
>>>>>>>>>
>>>>>>>>> On Thu, Nov 26, 2015 at 7:58 PM, Stian Thorgersen <
>>>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Please read the migration guide
>>>>>>>>>>
>>>>>>>>>> On 26 November 2015 at 14:53, Lohitha Chiranjeewa <
>>>>>>>>>> kalc04 at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> We're in the process of assessing the impact on upgrading from
>>>>>>>>>>> Keycloak 1.2.0 to 1.6.1. We came across an issue when trying to enable
>>>>>>>>>>> Infinispan cache through the keycloak-server.json file as we used to do in
>>>>>>>>>>> 1.2.0.
>>>>>>>>>>>
>>>>>>>>>>> We have the following entries in 1.6.1:
>>>>>>>>>>>     "realm": {
>>>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>>>     },
>>>>>>>>>>>
>>>>>>>>>>>     "user": {
>>>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>>>     },
>>>>>>>>>>>
>>>>>>>>>>>     "userSessionPersister": {
>>>>>>>>>>>         "provider": "infinispan"
>>>>>>>>>>>     },
>>>>>>>>>>> .........
>>>>>>>>>>>     "connectionsInfinispan": {
>>>>>>>>>>>         "default" : {
>>>>>>>>>>>             "cacheContainer" :
>>>>>>>>>>> "java:comp/env/infinispan/Keycloak"
>>>>>>>>>>>         }
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>> All configurations in 1.6.1 standalone-ha.xml file remains
>>>>>>>>>>> comparable (and correct to the best of our knowledge) with the ones in
>>>>>>>>>>> 1.2.0.
>>>>>>>>>>>
>>>>>>>>>>> With the above configs, when we start the Keycloak service the
>>>>>>>>>>> following error(s) get logged:
>>>>>>>>>>>
>>>>>>>>>>> 18:03:31,610 ERROR [org.jboss.msc.service.fail] (ServerService
>>>>>>>>>>> Thread Pool -- 64) MSC000001: Failed to start service
>>>>>>>>>>> jboss.undertow.deployment.default-server.default-host./auth:
>>>>>>>>>>> org.jboss.msc.service.StartException in service
>>>>>>>>>>> jboss.undertow.deployment.default-server.default-host./auth:
>>>>>>>>>>> java.lang.RuntimeException: Failed to construct public
>>>>>>>>>>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>>>>>>>>>     at
>>>>>>>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
>>>>>>>>>>>     at
>>>>>>>>>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
>>>>>>>>>>>     at org.jboss.threads.JBossThread.run(JBossThread.java:320)
>>>>>>>>>>> [jboss-threads-2.2.0.Final.jar:2.2.0.Final]
>>>>>>>>>>> Caused by: java.lang.RuntimeException: Failed to construct
>>>>>>>>>>> public
>>>>>>>>>>> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>>>>>>>>>>>     at
>>>>>>>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>>>>>>>>>>>     at
>>>>>>>>>>> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>>>>>>>>>>>     at
>>>>>>>>>>> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>>>>>>>>>>>     at
>>>>>>>>>>> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:230)
>>>>>>>>>>>     at
>>>>>>>>>>> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131)
>>>>>>>>>>>     at
>>>>>>>>>>> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511)
>>>>>>>>>>>     at
>>>>>>>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>>>>>>>>>>>     at
>>>>>>>>>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>>>>>>>>>>>     ... 6 more
>>>>>>>>>>> Caused by: java.lang.RuntimeException: Failed to find provider
>>>>>>>>>>> infinispan for realm
>>>>>>>>>>>     at
>>>>>>>>>>> org.keycloak.services.DefaultKeycloakSessionFactory.init(DefaultKeycloakSessionFactory.java:66)
>>>>>>>>>>>     at
>>>>>>>>>>> org.keycloak.services.resources.KeycloakApplication.createSessionFactory(KeycloakApplication.java:162)
>>>>>>>>>>>     at
>>>>>>>>>>> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:62)
>>>>>>>>>>>     at
>>>>>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:526)
>>>>>>>>>>> [rt.jar:1.7.0_45]
>>>>>>>>>>>     at
>>>>>>>>>>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>>>>>>>>>>>     ... 19 more
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is the new way to enable Infinispan different to what we had
>>>>>>>>>>> earlier? If so, can someone please point out the correct way?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Lohitha.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20151130/61f07ea9/attachment-0001.html

More information about the keycloak-user mailing list