It is not expected behavior. Users should only be invalidated if changes
are made.
On 30 November 2015 at 07:01, Lohitha Chiranjeewa <kalc04(a)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(a)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(a)redhat.com>
> wrote:
>
>> Strange - what are you doing and what are the SQL queries?
>>
>> On 27 November 2015 at 15:23, Lohitha Chiranjeewa <kalc04(a)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(a)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(a)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(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Yup, so it's working now?
>>>>>>
>>>>>> On 27 November 2015 at 13:20, Lohitha Chiranjeewa
<kalc04(a)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(a)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(a)redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Please read the migration guide
>>>>>>>>>
>>>>>>>>> On 26 November 2015 at 14:53, Lohitha Chiranjeewa
<
>>>>>>>>> kalc04(a)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(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>