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

Marek Posolda mposolda at redhat.com
Mon Apr 4 10:28:57 EDT 2016


Maybe for consistency, we can just add another "getInstance" like this:

public static Keycloak getInstance(String serverUrl, String realm, String username, String password, String clientId, String clientSecret, ResteasyClientresteasyClient){
     return new Keycloak(serverUrl, realm, username, password, clientId, clientSecret,resteasyClient);
}

That should be easy and not break anything regarding backwards 
compatibility. Marek On 04/04/16 15:08, Guus der Kinderen wrote:
> Thanks for the suggestion, but wouldn't that bypass the TokenManager?
> I've just ran a quick test with subclassing Keycloak to add another 
> getInstance(). That works fine.
> Why not make that constructor public? Do we want to hide the Resteasy 
> instance so bad?
>  - Guus
> On 4 April 2016 at 15:59, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     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 <mailto: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
>
>     _______________________________________________ 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160404/5e59d85d/attachment-0001.html 


More information about the keycloak-user mailing list