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

[Guus der Kinderen]

That would work for me. It's exactly what I did in the subclass.

On 4 April 2016 at 16:28, Marek Posolda <mposolda at redhat.com> wrote:

> 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, ResteasyClient resteasyClient){
>     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> 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>
>> 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> 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 listkeycloak-user at lists.jboss.orghttps://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
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>> _______________________________________________ keycloak-user mailing
>> list keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160404/152a15e1/attachment.html