8:32 p.m.
I am talking about some external authenticators (MIT Kerberos or SecurID) when KC will
wait for the response which can take a few seconds (the thread executing that call sits
idle during that time) -and it makes perfect sense in those cases to use async model. The
same applies to Identity Broker when KC opens up http connection to an external Identity
Provider (say ADFS - there could be delay of few seconds for the response to come back). I
had a quick look at the KC code and it appears that normal http blocking calls are being
made. Shifting to async will definitely help KC handle many more user requests. See the
below text from Apache http components website on when async model makes sense. Whether
you consider shifting to async or not is totally your call but shifting to async model
(infact using modern web frameworks/servers like Vertx) will future proof KC
functionality.
The blocking I/O model may be more appropriate for data intensive, low latency scenarios,
whereas the non-blocking model may be more appropriate for high latency scenarios where
raw data throughput is less important than the ability to handle thousands of simultaneous
HTTP connections in a resource efficient manner.
From: Bill Burke <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, March 30, 2016 9:43 AM
Subject: Re: [keycloak-dev] Async HTTP Request Processing
JAX-RS async can be enabled per resource, so its really up to you to decide if Authz
needs it.
Async doesn't make sense for core KC autthentication. KC Identity broker does not
wait/block for a response on a login. Authenticators are not waiting/blocking for
responses either. Waiting/blocking only happens on backchannel logouts and background
admin operations. Somebody is going to have to show me real tangible benefits before we
switch core KC to use Async JAX-RS or some async event driven SPI, because right now, with
our currently functionality and our roadmap, there is no need for an async model.
On 3/29/2016 9:57 PM, Raghuram Prabhala wrote:
+1. Makes sense for even KC (as Identity broker waiting for a response from Identity
provider or as Identity provider waiting for a response from Authenticators)
From: Pedro Igor Silva <psilva(a)redhat.com>
To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Sent: Tuesday, March 29, 2016 9:47 PM
Subject: [keycloak-dev] Async HTTP Request Processing
Hi,
I'm working with the AuthZ Java API in order to make it more event-driven and
non-blocking. During our F2F, I've discussed some very interesting requirements with
Marc Savy around that.
I would like to know if makes sense to enable JAX-RS Async support to some AuthZ REST
endpoints, which are basically using this API to evaluate policies using different
providers (where these providers can be executed in parallel).
Regards.
Pedro Igor
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev