<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 07/12/15 09:36, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAf7UTq6wdQ44z26xq6vqHYhkT0H23uGCnRdoucFWaexpQ@mail.gmail.com"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
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.<br>
<br>
Marek<br>
<br>
<blockquote
cite="mid:CAJgngAf7UTq6wdQ44z26xq6vqHYhkT0H23uGCnRdoucFWaexpQ@mail.gmail.com"
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 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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</body>
</html>