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)
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