[keycloak-user] Is Keycloak client admin thread safe?

[Bill Burke]

You can just create the ResteasyClient, get a ResteasyWebTarget, then 
call target.proxy(RealmsResource.class)

On 4/4/2016 8:52 AM, Guus der Kinderen wrote:
> Hey, thanks for this. Coincidentally, I was looking into similar issues.
>
> 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.
>
> 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?
>
> 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.
>
> Regards,
>
>   Guus
>
> On 31 March 2016 at 21:20, Hristo Stoyanov <hr.stoyanov at peruncs.com 
> <mailto:hr.stoyanov at peruncs.com>> wrote:
>
>     Marek,
>     Thanks for this clarification and all your help in this forum to
>     my other questions!
>
>     You guys rock!
>
>     /Hristo Stoyanov
>
>     On Mar 31, 2016 2:38 AM, "Marek Posolda" <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         It's supposed to be and we even internally using it in some
>         concurrency test.
>
>         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.
>
>         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 https://issues.jboss.org/browse/KEYCLOAK-2731 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.
>
>         Marek
>
>
>         On 31/03/16 01:37, Hristo Stoyanov wrote:
>>
>>         Is org.Keycloak.admin.client.Keycloak threadsafe? I intend to
>>         use it as a single admin client for the entire app ...
>>
>>         /Hristo Stoyanov
>>
>>
>>
>>         _______________________________________________
>>         keycloak-user mailing list
>>         keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160404/118d6aff/attachment.html