<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2015 at 09:56, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 07/12/15 09:36, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<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>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>
</div>
</div>
</blockquote></span>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><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><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><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><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><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>
<div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">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>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>