[keycloak-user] How to enable Infinispan cache for realms, users and user sessions in Keycloak 1.6.1?
Lohitha Chiranjeewa
kalc04 at gmail.com
Mon Nov 30 11:53:19 EST 2015
Step 1 just at the start and then steps 2-4 in concurrent threads for
different users. The user base is about 40 so after a couple of cycles all
user details should be retrieved from cache I guess.
We have default values for hash iterations. And I can guarantee that there
isn't any other operations going on at that time.
On Nov 30, 2015 8:39 PM, "Bill Burke" <bburke at redhat.com> wrote:
> You do steps 1-4 in a continuous loop? or do you just get the token once
> and do steps 2-4 in a continuous loop?
>
> I want to figure out why you are getting so many invalidation messages,
> but there are other things that can peg the cpu. If you are using a large
> value for password hash iterations, this can peg the CPU very quickly on a
> small number of threads.
>
> On 11/30/2015 9:49 AM, Lohitha Chiranjeewa wrote:
>
>> Bill,
>>
>> This particular load test consists of four API calls, starts with
>> authentication:
>>
>> 1) Invoke {host}/auth/realms/xxxx/protocol/openid-connect/token with
>> "|username={username}&password={password}&grant_type=password|" as the
>> body - we get the Access Token from this and use it for subsequent API
>> calls
>> 2) Get user by User ID
>> 3) Get Realm Roles of above user
>> 4) Get Client Roles of a single given client for above user
>>
>> We run this test suite with concurrent threads (same superuser for
>> authentication, but steps 2,3,4 for different users). But with our 2
>> highly available M3-Medium server setup, it is impossible to go beyond
>> 10-15 threads w/o the processor hitting 100% usage.
>>
>> During the tests, we see millions (figuratively) of invalidation logs
>> like this:
>> [2015-11-30 14:32:08.0823], DEBUG,
>> org.infinispan.interceptors.InvalidationInterceptor Timer-2 - Cache
>> [dev-idm-a1] replicating
>> InvalidateCommand{keys=[40113545-5069-47c4-bf1c-8f58a303caf6]}
>>
>>
>> Regards,
>> Lohitha.
>>
>> On Mon, Nov 30, 2015 at 8:17 PM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>> I just did a loop test on GET
>> https://{host}/auth/admin/realms/xxxxx/users/xxxx. The same userid
>> over and over as you described. I see zero invalidations. Are you
>> sure you aren't doing any updates?
>>
>> On 11/30/2015 9:33 AM, Stian Thorgersen wrote:
>>
>> If you can try building master and enable trace logging for
>>
>> "org.keycloak.models.cache.infinispan.InfinispanCacheUserProviderFactory".
>> It will print log statements when entries are
>> removed/invalidated in the
>> cache.
>>
>> On 30 November 2015 at 15:19, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>
>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>>
>> Can you describe your load tests please? What kind of
>> authentication
>> are you doing? The only thing that would cause
>> invalidations is HOTP.
>>
>> On 11/30/2015 9:13 AM, Lohitha Chiranjeewa wrote:
>> > Bill, the problem here is that our load tests cannot go
>> beyond a paltry
>> > 15-20 concurrent threads with the default set up
>> (invalidation caches
>> > with SYNC mode - two HA AWS M3-Medium servers). Hence
>> we're trying to
>> > find ways to improve on the performance and the avg
>> response time under
>> > a load.
>> >
>> > On Mon, Nov 30, 2015 at 7:16 PM, Bill Burke
>> <bburke at redhat.com <mailto:bburke at redhat.com>
>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>
>> > <mailto:bburke at redhat.com <mailto:bburke at redhat.com>
>> <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>> wrote:
>> >
>> > BTW, besides being more scalable, we invalidate
>> rather than replicate to
>> > avoid transmitting sensitive security data over the
>> network.
>> >
>> > On 11/30/2015 8:29 AM, Lohitha Chiranjeewa wrote:
>> > > Glad if you could look into the above and check if
>> there are app level
>> > > issues related to invalidations, thanks.
>> > >
>> > > One way to get around this through config changes
>> is to make the
>> > > relevant cache modes 'ASYNC' and set up suitable
>> values for 'queue-size'
>> > > and 'queue-flush-interval' depending on your needs.
>> Then the
>> > > invalidations won't happen with each and every call.
>> > >
>> > > Obviously there would be problems if caches aren't
>> invalidated in time
>> > > with the above set up, it's up to the devs to come
>> up with a suitable
>> > > set of configs to cater to their needs.
>> > >
>> > >
>> > > Regards,
>> > > Lohitha.
>> > >
>> > >
>> > >
>> > > On Mon, Nov 30, 2015 at 1:08 PM, Stian Thorgersen
>> <sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>
>> > > <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>>>
>> wrote:
>> > >
>> > > 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 <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> > > <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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
>> <mailto:kalc04 at gmail.com> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> > <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>
>> > <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto: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
>> <mailto:kalc04 at gmail.com> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> > <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>
>> > <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>> > <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto: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 <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> > > <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>> <mailto:kalc04 at gmail.com
>> <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>
>> > >
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>>>
>> wrote:
>> > >
>> > > Yup, so it's
>> working now?
>> > >
>> > > On 27 November 2015
>> at 13:20, Lohitha
>> > > Chiranjeewa
>> <kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> > >
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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 <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> > >
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>>
>> > <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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 <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>> > <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com> <mailto:sthorger at redhat.com
>> <mailto:sthorger at redhat.com>>>
>> > >
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>
>> <mailto:sthorger at redhat.com <mailto:sthorger at redhat.com>>>>>
>> wrote:
>> > >
>> > > Please
>> read the migration guide
>> > >
>> > > On 26
>> November 2015 at
>> > > 14:53,
>> Lohitha Chiranjeewa
>> > >
>> <kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>>
>> > >
>> > <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>>
>>
>> <mailto:kalc04 at gmail.com <mailto:kalc04 at gmail.com>
>> <mailto:kalc04 at gmail.com <mailto: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
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>>
>> > >
>> > <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>
>> > <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>>>
>> > >
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > keycloak-user mailing list
>> > >keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> <mailto:keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>>>
>> > >
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> > >
>> >
>> > --
>> > Bill Burke
>> > JBoss, a division of Red Hat
>> >http://bill.burkecentral.com
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> <mailto: <keycloak-user at lists.jboss.org>
>
> ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20151130/40fe3152/attachment-0001.html
More information about the keycloak-user
mailing list