[
https://issues.apache.org/jira/browse/GEODE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7283:
------------------------------
Description:
When using security, the OQL method authorizer is instantiated multiple times
during the OQL execuion, incurring into a waste of time and resources.
The authorizer is obtained through the
{{queryContext.getCache().getQueryService().getMethodInvocationAuthorizer()}}
method, which basically creates a new instance of the {{DefaultQueryService}}
and, also, a new instance of the {{MethodInvocationAuthorizer}} configured:
{code:java|title=DefaultQueryService.java|borderStyle=solid}
public DefaultQueryService(InternalCache cache) {
if (cache == null)
throw new IllegalArgumentException("cache must not be null");
this.cache = cache;
if (!cache.getSecurityService().isIntegratedSecurity() ||
ALLOW_UNTRUSTED_METHOD_INVOCATION) {
// A no-op authorizer, allow method invocation
this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
} else {
this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
}
}
{code}
When using implicit method invocation, the above implies that the authorizer
will be created X times per query, being X the amount of attributes accessed
per object multiplied by the amount of objects traversed by the query. As an
example, if we have a region with 100 entries (entry has a non-public {{name}}
attribute with a public {{getName()}} accessor) and we execute {{SELECT o.name
FROM /Region o}}, the {{MethodInvocationAuthorizer}} will be instantiated 100
times.
When using explicit method invocation things are "better": the
{{MethodInvocationAuthorizer}} is only created once for every new (unknown)
method during the lifetime of the Geode member, and that's basically because
the {{MethodDispatch}} class is internally cached and it also has the
{{MethodInvocationAuthorizer}} used when it was created stored internally. This
incurs into another problem: once a {{MethodDispatch}} is created, the
{{MethodInvocationAuthorizer}} can't be changed, the user needs to restart the
member in order to clear the cache ({{CompiledOperation}}) and force the query
engine to execute a new lookup of the now unknown method (which must also be
done through the API when implementing GEODE-6991, otherwise changes won't be
applied).
The {{MethodInvocationAuthorizer}} should be unique and unchangeable during
the execution of a particular query on a particular member, so we should
investigate whether it would make sense to create it only once at the beginning
of the query execution and have it directly available as part of the
{{QueryExecutionContext}}.
was:
When using security, the OQL method authorizer is instantiated multiple times
during the OQL execuion, incurring into a waste of time and resources.
The authorizer is obtained through the
{{queryContext.getCache().getQueryService().getMethodInvocationAuthorizer()}}
method, which basically creates a new instance of the {{DefaultQueryService}}
and, also, a new instance of the {{MethodInvocationAuthorizer}} configured:
{code:title=DefaultQueryService.java|borderStyle=solid}
public DefaultQueryService(InternalCache cache) {
if (cache == null)
throw new IllegalArgumentException("cache must not be null");
this.cache = cache;
if (!cache.getSecurityService().isIntegratedSecurity() ||
ALLOW_UNTRUSTED_METHOD_INVOCATION) {
// A no-op authorizer, allow method invocation
this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
} else {
this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
}
}
{code}
When using implicit method invocation, the above implies that the authorizer
will be created X times per query, being X the amount of attributes accessed
per object multiplied by the amount of objects traversed by the query. As an
example, if we have a region with 100 entries (entry has a non-public {{name}}
attribute with a public {{getName()}} accessor) and we execute {{SELECT o.name
FROM /Region o}}, the {{MethodInvocationAuthorizer}} will be instantiated 100
times.
When using explicit method invocation things are "better": the
{{MethodInvocationAuthorizer}} is only created once for every new (unknown)
method during the lifetime of the Geode member, and that's basically because
the {{MethodDispatch}} class is internally cached and it also has the
{{MethodInvocationAuthorizer}} used when it was created stored internally. This
incurs into another problem: once a {{MethodDispatch}} is created, the
{{MethodInvocationAuthorizer}} can't be changed, the user needs to restart the
member in order to clear the cache ({{CompiledOperation}}) and force the query
engine to execute a new lookup of the now unknown method (which must also be
done through the API when implementing GEODE-6991, otherwise changes won't be
applied).
The {{MethodInvocationAuthorizer}} should be unique and unchangeable during the
execution of a particular query on a particular member, so we should
investigate whether it would make sense to create it only once a the beginning
of the query execution and have it directly available as part of the
{{QueryExecutionContext}}.
> OQL Method Authorizer in Query Execution Context
> ------------------------------------------------
>
> Key: GEODE-7283
> URL: https://issues.apache.org/jira/browse/GEODE-7283
> Project: Geode
> Issue Type: Improvement
> Components: querying
> Reporter: Juan Ramos
> Priority: Major
> Labels: GeodeCommons
>
> When using security, the OQL method authorizer is instantiated multiple times
> during the OQL execuion, incurring into a waste of time and resources.
> The authorizer is obtained through the
> {{queryContext.getCache().getQueryService().getMethodInvocationAuthorizer()}}
> method, which basically creates a new instance of the {{DefaultQueryService}}
> and, also, a new instance of the {{MethodInvocationAuthorizer}} configured:
> {code:java|title=DefaultQueryService.java|borderStyle=solid}
> public DefaultQueryService(InternalCache cache) {
> if (cache == null)
> throw new IllegalArgumentException("cache must not be null");
> this.cache = cache;
> if (!cache.getSecurityService().isIntegratedSecurity() ||
> ALLOW_UNTRUSTED_METHOD_INVOCATION) {
> // A no-op authorizer, allow method invocation
> this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
> } else {
> this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
> }
> }
> {code}
> When using implicit method invocation, the above implies that the authorizer
> will be created X times per query, being X the amount of attributes accessed
> per object multiplied by the amount of objects traversed by the query. As an
> example, if we have a region with 100 entries (entry has a non-public
> {{name}} attribute with a public {{getName()}} accessor) and we execute
> {{SELECT o.name FROM /Region o}}, the {{MethodInvocationAuthorizer}} will be
> instantiated 100 times.
> When using explicit method invocation things are "better": the
> {{MethodInvocationAuthorizer}} is only created once for every new (unknown)
> method during the lifetime of the Geode member, and that's basically because
> the {{MethodDispatch}} class is internally cached and it also has the
> {{MethodInvocationAuthorizer}} used when it was created stored internally.
> This incurs into another problem: once a {{MethodDispatch}} is created, the
> {{MethodInvocationAuthorizer}} can't be changed, the user needs to restart
> the member in order to clear the cache ({{CompiledOperation}}) and force the
> query engine to execute a new lookup of the now unknown method (which must
> also be done through the API when implementing GEODE-6991, otherwise changes
> won't be applied).
> The {{MethodInvocationAuthorizer}} should be unique and unchangeable during
> the execution of a particular query on a particular member, so we should
> investigate whether it would make sense to create it only once at the
> beginning of the query execution and have it directly available as part of
> the {{QueryExecutionContext}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
