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

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(a)redhat.com <mailto:bburke@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(a)peruncs.com <mailto:hr.stoyanov@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(a)redhat.com > <mailto:mposolda@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(a)lists.jboss.org >> <mailto:keycloak-user@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ keycloak-user > mailing list keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org <mailto:keycloak-user@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(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user