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@redhat.com>
To: keycloak-dev <keycloak-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com