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?- GuusOn 4 April 2016 at 15:59, Bill Burke <bburke@redhat.com> wrote:You can just create the ResteasyClient, get a ResteasyWebTarget, then call target.proxy(RealmsResource.class)_______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-userOn 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,GuusOn 31 March 2016 at 21:20, Hristo Stoyanov <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
_______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-userOn Mar 31, 2016 2:38 AM, "Marek Posolda" <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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user_______________________________________________ keycloak-user mailing list 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user