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

[Guus der Kinderen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160404/ca266b40/attachment.html