[keycloak-dev] Realm cache

[Stian Thorgersen]

I think it's ok for 1.x. We just need to make sure there's not to many
invalidation messages sent to the cluster. If an invalidation of a realm
results in a message for the realm and one message for each client, role
and group, it's not going to be very nice.

On 7 December 2015 at 09:56, Marek Posolda <mposolda at redhat.com> wrote:

> On 07/12/15 09:36, Stian Thorgersen wrote:
>
>
>
> On 3 December 2015 at 16:10, Bill Burke <bburke at redhat.com> wrote:
>
>> On 12/3/2015 7:50 AM, Stian Thorgersen wrote:
>> > There's still some outstanding issues with the realm cache. It works,
>> > but can and should be improved for 1.8.
>> >
>> > One issue was that once the realm is updated any methods on clients,
>> > roles or groups returns the underlying adapter instead of the cache
>> > adapters. As a work around in 1.7 it now ejects all clients for a realm
>> > when it sees any changes.
>> >
>>
>> Why is that a bad thing?  Usually, roles groups, and clients are not
>> accessed in the same session as a realm update.  Realms are usually not
>> updated.  Client registration/unregistration is rare too for most apps.
>>   The vast majority (90%+?) of access is read-only for realms and clients.
>>
>
> The problem is that once you return the jpa client adapter instead of the
> cache client adapter the cache no longer knows it should be invalidated. So
> if you do:
>
>     realm.set...
>     client = realm.getClientById("")
>     client.set...
>
> The realm is invalidated, but not the client. That's why I had to add a
> work-around that invalidates all clients of a realm when the realm is
> changed.
>
> I agree writes are rare. If we end up invalidating everything for a realm
> for every update that's not a good thing either though.
>
> Depends. It seems that update realm settings is so rare operation, that
> it's likely not a problem to be rather defensive and invalidate everything
> (unless we figure out easy and safe way to not do it). On the other hand
> add/remove role is possibly more common, so here we should be likely more
> smart in invalidating stuff.
>
> Marek
>
>
>
> Also, we need to consider the way things are invalidated. Sending a single
> message to the cluster that a realm is invalidated is ok. However, if we
> send a message for each realm, client and role for each update that would
> be terrible.
>
>
>
>>
>> > We have a few potential ways to solve this:
>> >
>> > a) try to always return cache adapters - I went down this road attacking
>> > it from a few different approaches, but was never successful as there
>> > was always something that didn't work
>>
>> See above, I don't think this is an issue.  What we should do is
>> identify if any updates are performed on realms/clients per login/token
>> refresh and remove or isolate them so that the realm/client caches
>> aren't invalidated.
>>
>
> +1 At least for 1.x that would be the target. After 1.x I'd like to have a
> separate store for clients like we do for users. I think in some scenarios
> there may be 1K+ clients.
>
>
>>
>> > b) only cache realms and have everything else hang off it - this is my
>> > preferred option for now. As long as updating clients requires
>> > invalidating the realm it seems a bit over the top to have separate
>> > caches for everything
>>
>> Why can't you keep it as it is?
>>
>> RealmAdapter.getDelegateForUpdate() always registers a realm
>> invalidation.  add/remove client are methods on RealmModel so the realm
>> cache was always invalidated.  The only time you need to invalidate the
>> realm is when clientId is changed.
>>
>
> As I said above if realm returns jpa adapter for clients when you retrieve
> clients then updates to clients are not visible to the cache after the
> realm has been updated.
>
>
>>
>> > c) make the cache smarter - instead of invalidating a realm, make sure
>> > we add/remove the clients, etc..
>> >
>>
>> Its an invalidation cache, so "C" won't work unless you have a separate
>> cache for the client list.  So you'd need a realm cache, client list
>> cache, and client cache.
>>
>> > We also need more automated testing around clustering. Late in 1.7
>> > release process I identified that caches where invalidated when other
>> > nodes loaded things to it, so effectively the cache wasn't working at
>> > all in a cluster.
>> >
>> > Thoughts?
>> >
>>
>> I think this is a bit of effort for little gain.  users will only see a
>> difference if there is a lot of realm adminstration happening.
>>
>
> For small/medium installations there's probably little realm admin going
> on. However, on big installations where performance is crucial I imagine
> that some admin is going to be relatively frequent so it's worth limiting
> what is invalidated.
>
>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151207/f1656765/attachment.html