6:37 p.m.
Is org.Keycloak.admin.client.Keycloak threadsafe? I intend to use it as a
single admin client for the entire app ...
/Hristo Stoyanov
4:38 a.m.
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
https://lists.jboss.org/mailman/listinfo/keycloak-user
2:20 p.m.
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> 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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
7:52 a.m.
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> 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> 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@lists.jboss.orghttps://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
8:59 a.m.
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
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:08 a.m.
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> 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>
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>
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@lists.jboss.orghttps://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
>
_______________________________________________
keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
9:28 a.m.
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(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
9:44 a.m.
That would work for me. It's exactly what I did in the subclass.
On 4 April 2016 at 16:28, Marek Posolda <mposolda(a)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(a)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>
> 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>
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@lists.jboss.orghttps://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
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing
listkeycloak-user@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
3192
days inactive
3197
days old
7 comments
4 participants
participants (4)
-
Bill Burke -
Guus der Kinderen -
Hristo Stoyanov -
Marek Posolda