+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&gt; To: keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; 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

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&gt; 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&gt; To: keycloak-dev <keycloak-dev(a)lists.jboss.org&gt; 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