10:15 a.m.
I don't understand why async-http support for JAXRS is being used for
Authz requests. Async HTTP is only useful when you want to limit the
amount of long running requests or you have an operation that may block
for some time. Do you want to limit the number of authz requests that
can happen at one time? Or, do you have an operation that may block?
Otherwise I don't see the point of using async HTTP. It complicates the
code.
Looking at your ScheduledPermissionEvaluator you aren't even using the
Executor that is passed into the constructor so its all happening in the
same thread anyways.
Bill
10:33 a.m.
I say this because I'm trying to run the policy evaluator within the IDE
within the arquillian testsuite and it is failing. We have regular
non-async servlet filters in Keycloak. Undertow now checks to see if
there are any non-async servlet filters and won't allow async http.
On 4/1/17 11:15 AM, Bill Burke wrote:
I don't understand why async-http support for JAXRS is being used
for
Authz requests. Async HTTP is only useful when you want to limit the
amount of long running requests or you have an operation that may
block for some time. Do you want to limit the number of authz
requests that can happen at one time? Or, do you have an operation
that may block? Otherwise I don't see the point of using async HTTP.
It complicates the code.
Looking at your ScheduledPermissionEvaluator you aren't even using the
Executor that is passed into the constructor so its all happening in
the same thread anyways.
Bill
1:16 p.m.
As you noticed with the ScheduledPermissionEvaluator, policy evaluation is
a blocking operation. The idea is provide in the future ways to configure
an executor and allow more authz requests happening in parallel with
complete control over how it is done.
Right now, yes. We don't have this yet but just using a single thread.
Some time ago I did some tests using executors but I had no success mainly
because of issues with JPA EntityManager.
I'm OK to remove async for now but keep an eye on the future for future
improvements in this area.
Regards.
Pedro Igor
On Sat, Apr 1, 2017 at 12:33 PM, Bill Burke <bburke(a)redhat.com> wrote:
I say this because I'm trying to run the policy evaluator within
the IDE
within the arquillian testsuite and it is failing. We have regular
non-async servlet filters in Keycloak. Undertow now checks to see if
there are any non-async servlet filters and won't allow async http.
On 4/1/17 11:15 AM, Bill Burke wrote:
> I don't understand why async-http support for JAXRS is being used for
> Authz requests. Async HTTP is only useful when you want to limit the
> amount of long running requests or you have an operation that may
> block for some time. Do you want to limit the number of authz
> requests that can happen at one time? Or, do you have an operation
> that may block? Otherwise I don't see the point of using async HTTP.
> It complicates the code.
>
> Looking at your ScheduledPermissionEvaluator you aren't even using the
> Executor that is passed into the constructor so its all happening in
> the same thread anyways.
>
> Bill
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:22 p.m.
Btw, the main design around the AuthZ API was provide a async and
non-blocking API for policy evaluation.
On Sat, Apr 1, 2017 at 12:15 PM, Bill Burke <bburke(a)redhat.com> wrote:
I don't understand why async-http support for JAXRS is being used
for
Authz requests. Async HTTP is only useful when you want to limit the
amount of long running requests or you have an operation that may block
for some time. Do you want to limit the number of authz requests that
can happen at one time? Or, do you have an operation that may block?
Otherwise I don't see the point of using async HTTP. It complicates the
code.
Looking at your ScheduledPermissionEvaluator you aren't even using the
Executor that is passed into the constructor so its all happening in the
same thread anyways.
Bill
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:17 p.m.
Can only one authz request be executed concurrently at one time? If so,
why? Or is it just implemented so that in the future you can execute
multiple requests simultaneously?
This seems like overkill. How complex do you expect these policies to get?
On 4/1/17 2:16 PM, Pedro Igor Silva wrote:
As you noticed with the ScheduledPermissionEvaluator, policy
evaluation is a blocking operation. The idea is provide in the future
ways to configure an executor and allow more authz requests happening
in parallel with complete control over how it is done.
Right now, yes. We don't have this yet but just using a single thread.
Some time ago I did some tests using executors but I had no success
mainly because of issues with JPA EntityManager.
I'm OK to remove async for now but keep an eye on the future for
future improvements in this area.
Regards.
Pedro Igor
On Sat, Apr 1, 2017 at 12:33 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
I say this because I'm trying to run the policy evaluator within
the IDE
within the arquillian testsuite and it is failing. We have regular
non-async servlet filters in Keycloak. Undertow now checks to see if
there are any non-async servlet filters and won't allow async http.
On 4/1/17 11:15 AM, Bill Burke wrote:
> I don't understand why async-http support for JAXRS is being
used for
> Authz requests. Async HTTP is only useful when you want to
limit the
> amount of long running requests or you have an operation that may
> block for some time. Do you want to limit the number of authz
> requests that can happen at one time? Or, do you have an operation
> that may block? Otherwise I don't see the point of using async
HTTP.
> It complicates the code.
>
> Looking at your ScheduledPermissionEvaluator you aren't even
using the
> Executor that is passed into the constructor so its all happening in
> the same thread anyways.
>
> Bill
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
2:38 p.m.
Yes, a single authz requests could be executed concurrently. This is
because an authz request may span different permissions. For instance, give
me permissions for resource A, B, C, etc. So we could gain some performance
by avoiding a serial processing of these permissions. I did some tests a
long time ago and the results were really interesting when using policies
that can run slow like Drools.
Another scenario is handle multiple requests concurrently. Like I said, the
idea was make this configurable and let users define what is best for their
deployments.
How complex I expect policies to get ? I don't know. But we can not discard
that you can have any policy you want and that may impact performance. Take
Drools as an example ... Although they improved *a lot* performance on 6.4,
depending on how you define your rules or how many are involved in a single
permission evaluation, you may have issues with performance.
On Sat, Apr 1, 2017 at 4:17 PM, Bill Burke <bburke(a)redhat.com> wrote:
Can only one authz request be executed concurrently at one time? If
so,
why? Or is it just implemented so that in the future you can execute
multiple requests simultaneously?
This seems like overkill. How complex do you expect these policies to
get?
On 4/1/17 2:16 PM, Pedro Igor Silva wrote:
As you noticed with the ScheduledPermissionEvaluator, policy evaluation
is a blocking operation. The idea is provide in the future ways to
configure an executor and allow more authz requests happening in parallel
with complete control over how it is done.
Right now, yes. We don't have this yet but just using a single thread.
Some time ago I did some tests using executors but I had no success mainly
because of issues with JPA EntityManager.
I'm OK to remove async for now but keep an eye on the future for future
improvements in this area.
Regards.
Pedro Igor
On Sat, Apr 1, 2017 at 12:33 PM, Bill Burke <bburke(a)redhat.com> wrote:
> I say this because I'm trying to run the policy evaluator within the IDE
> within the arquillian testsuite and it is failing. We have regular
> non-async servlet filters in Keycloak. Undertow now checks to see if
> there are any non-async servlet filters and won't allow async http.
>
>
> On 4/1/17 11:15 AM, Bill Burke wrote:
> > I don't understand why async-http support for JAXRS is being used for
> > Authz requests. Async HTTP is only useful when you want to limit the
> > amount of long running requests or you have an operation that may
> > block for some time. Do you want to limit the number of authz
> > requests that can happen at one time? Or, do you have an operation
> > that may block? Otherwise I don't see the point of using async HTTP.
> > It complicates the code.
> >
> > Looking at your ScheduledPermissionEvaluator you aren't even using the
> > Executor that is passed into the constructor so its all happening in
> > the same thread anyways.
> >
> > Bill
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2607
days inactive
2607
days old
5 comments
2 participants
participants (2)
-
Bill Burke -
Pedro Igor Silva