<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 December 2015 at 16:10, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/3/2015 7:50 AM, Stian Thorgersen wrote:<br>
> There's still some outstanding issues with the realm cache. It works,<br>
> but can and should be improved for 1.8.<br>
><br>
> One issue was that once the realm is updated any methods on clients,<br>
> roles or groups returns the underlying adapter instead of the cache<br>
> adapters. As a work around in 1.7 it now ejects all clients for a realm<br>
> when it sees any changes.<br>
><br>
<br>
</span>Why is that a bad thing? Usually, roles groups, and clients are not<br>
accessed in the same session as a realm update. Realms are usually not<br>
updated. Client registration/unregistration is rare too for most apps.<br>
The vast majority (90%+?) of access is read-only for realms and clients.<br></blockquote><div><br></div><div>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:</div><div><br></div><div> realm.set...</div><div> client = realm.getClientById("")</div><div> client.set...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> We have a few potential ways to solve this:<br>
><br>
> a) try to always return cache adapters - I went down this road attacking<br>
> it from a few different approaches, but was never successful as there<br>
> was always something that didn't work<br>
<br>
</span>See above, I don't think this is an issue. What we should do is<br>
identify if any updates are performed on realms/clients per login/token<br>
refresh and remove or isolate them so that the realm/client caches<br>
aren't invalidated.<br></blockquote><div><br></div><div>+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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> b) only cache realms and have everything else hang off it - this is my<br>
> preferred option for now. As long as updating clients requires<br>
> invalidating the realm it seems a bit over the top to have separate<br>
> caches for everything<br>
<br>
</span>Why can't you keep it as it is?<br>
<br>
RealmAdapter.getDelegateForUpdate() always registers a realm<br>
invalidation. add/remove client are methods on RealmModel so the realm<br>
cache was always invalidated. The only time you need to invalidate the<br>
realm is when clientId is changed.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> c) make the cache smarter - instead of invalidating a realm, make sure<br>
> we add/remove the clients, etc..<br>
><br>
<br>
</span>Its an invalidation cache, so "C" won't work unless you have a separate<br>
cache for the client list. So you'd need a realm cache, client list<br>
cache, and client cache.<br>
<span class=""><br>
> We also need more automated testing around clustering. Late in 1.7<br>
> release process I identified that caches where invalidated when other<br>
> nodes loaded things to it, so effectively the cache wasn't working at<br>
> all in a cluster.<br>
><br>
> Thoughts?<br>
><br>
<br>
</span>I think this is a bit of effort for little gain. users will only see a<br>
difference if there is a lot of realm adminstration happening.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div></div>