<div dir="ltr">Thanks for the suggestion, but wouldn't that bypass the TokenManager?<div><br></div><div>I've just ran a quick test with subclassing Keycloak to add another getInstance(). That works fine. </div><div><br></div><div>Why not make that constructor public? Do we want to hide the Resteasy instance so bad?</div><div><br></div><div> - Guus</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 April 2016 at 15:59, 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">
<div bgcolor="#FFFFFF" text="#000000">
You can just create the ResteasyClient, get a ResteasyWebTarget,
then call target.proxy(RealmsResource.class)<div><div class="h5"><br>
<br>
<div>On 4/4/2016 8:52 AM, Guus der Kinderen
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey, thanks for this. Coincidentally, I was looking
into similar issues.
<div><br>
</div>
<div>We've been running into concurrently-related issues. These
find their origin in the Resteasy client that is created in
the client admin Keycloak class.</div>
<div><br>
</div>
<div>Marek writes that the underlying connection pool can be
modified, but that's not really straightforward: there is no
getInstance() method that exposes the Resteasy client. One has
to subclass the Keycloak class to gain access. Perhaps there's
room for improvement here?</div>
<div><br>
</div>
<div>Also, by default, the Resteasy client uses one connection.
That seems to be a very conservative default, given the nature
of the client admin. I believe that the client admin would
benefit from using a thread pool of a size that's arbitrarily
larger than 1. I'd go with 10.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div> Guus</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 31 March 2016 at 21:20, Hristo
Stoyanov <span dir="ltr"><<a href="mailto:hr.stoyanov@peruncs.com" target="_blank">hr.stoyanov@peruncs.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Marek,<br>
Thanks for this clarification and all your help in this
forum to my other questions!</p>
<p dir="ltr">You guys rock!</p>
<span><font color="#888888">
<p dir="ltr">/Hristo Stoyanov</p>
</font></span>
<div>
<div>
<div class="gmail_quote">On Mar 31, 2016 2:38 AM, "Marek
Posolda" <<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>It's supposed to be and we even internally
using it in some concurrency test. <br>
<br>
It's using Apache HTTP client under the hood,
which itself is thread-safe and is using
connection pooling. In case you need, you can
configure more fine-grained details (like
connection pool size etc) by pass the custom
resteasyClient to Keycloak object.<br>
<br>
However when I looked a bit more into sources
now, I can see that there are some potential
concurrency issues in TokenManager class, which
is used internally by admin client. Created JIRA
<a href="https://issues.jboss.org/browse/KEYCLOAK-2731" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2731</a>
for it. It's not too bad IMO, but note that you
can possibly see situation when more concurrent
threads are trying to refresh the same access
token at the same time.<br>
<br>
Marek<br>
<br>
<br>
On 31/03/16 01:37, Hristo Stoyanov wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Is
org.Keycloak.admin.client.Keycloak threadsafe?
I intend to use it as a single admin client
for the entire app ...</p>
<p dir="ltr">/Hristo Stoyanov</p>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</font></span></div>
<br>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>