[jira] [Commented] (GEODE-7284) A durable client's CacheClientProxy is sometimes not being kept on the server when it should be
[
https://issues.apache.org/jira/browse/GEODE-7284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948087#comment-16948087
]
ASF subversion and git services commented on GEODE-7284:
Commit 7f1ca0c85192b46919f40f9d6748e3d7922d7c8b in geode's branch
refs/heads/feature/GEODE-7284 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7f1ca0c ]
GEODE-7284: Modified CacheClientProxy remoteHostAddress to be unique
> A durable client's CacheClientProxy is sometimes not being kept on the server
> when it should be
> ---
>
> Key: GEODE-7284
> URL: https://issues.apache.org/jira/browse/GEODE-7284
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Barrett Oglesby
>Priority: Major
>
> A durable client's CacheClientProxy is sometimes not being kept on the server
> when it should be
> When a durable client is killed, logging for it on the server should look
> like:
> {noformat}
> [info 2019/10/09 16:40:42.426 PDT
> tid=0x110] CacheClientNotifier: Keeping proxy for durable client named
> client-9 for 300 seconds
> CacheClientProxy[identity(192.168.1.4(client:36729:loner):59887:9507e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-9;
> timeout=300]); port=59892; primary=true; version=GEODE 1.11.0].
> [info 2019/10/09 16:40:42.413 PDT 192.168.1.4(client:36478:loner):59353:71a9e3b2:client (client-9)> tid=0x6e]
> CacheClientProxy[identity(192.168.1.4(client:36729:loner):59887:9507e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-9;
> timeout=300]); port=59892; primary=true; version=GEODE 1.11.0] : Pausing
> processing
> {noformat}
> Sometimes, the logging looks like: (with log-level=fine):
> {noformat}
> [info 2019/10/09 16:40:42.429 PDT 192.168.1.4(client:36458:loner):59317:baa2e3b2:client (client-5)> tid=0x60]
> CacheClientProxy[identity(192.168.1.4(client:36717:loner):59851:3301e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-5;
> timeout=300]); port=59856; primary=true; version=GEODE 1.11.0] : Pausing
> processing
> [debug 2019/10/09 16:40:42.428 PDT 176> tid=0x102] CacheClientNotifier: Not keeping proxy for non-durable
> client:
> CacheClientProxy[identity(192.168.1.4(client:36717:loner):59851:3301e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-5;
> timeout=300]); port=59856; primary=true; version=GEODE 1.11.0]
> {noformat}
> On one hand, the Client Message Dispatcher is pausing, but on the other hand,
> the CacheClientProxy is not being kept.
> Thats because of this RejectedExecutionException thrown attempting to
> asynchronously close the CacheClientProxy's socket:
> {noformat}
> java.util.concurrent.RejectedExecutionException
> at
> java.base/java.util.concurrent.ForkJoinPool.externalPush(ForkJoinPool.java:1880)
> at
> java.base/java.util.concurrent.ForkJoinPool.externalSubmit(ForkJoinPool.java:1921)
> at
> java.base/java.util.concurrent.ForkJoinPool.submit(ForkJoinPool.java:2497)
> at
> java.base/java.util.concurrent.ForkJoinPool.submit(ForkJoinPool.java:178)
> at
> org.apache.geode.internal.net.SocketCloser.asyncExecute(SocketCloser.java:163)
> at
> org.apache.geode.internal.net.SocketCloser.asyncClose(SocketCloser.java:191)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeSocket(CacheClientProxy.java:955)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeTransientFields(CacheClientProxy.java:963)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.pauseDispatching(CacheClientProxy.java:839)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.close(CacheClientProxy.java:788)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.closeDeadProxies(CacheClientNotifier.java:1563)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.unregisterClient(CacheClientNotifier.java:567)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitor.unregisterClient(ClientHealthMonitor.java:255)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:961)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:882)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1223)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
>
[jira] [Created] (GEODE-7284) A durable client's CacheClientProxy is sometimes not being kept on the server when it should be
Barrett Oglesby created GEODE-7284:
--
Summary: A durable client's CacheClientProxy is sometimes not
being kept on the server when it should be
Key: GEODE-7284
URL: https://issues.apache.org/jira/browse/GEODE-7284
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Barrett Oglesby
A durable client's CacheClientProxy is sometimes not being kept on the server
when it should be
When a durable client is killed, logging for it on the server should look like:
{noformat}
[info 2019/10/09 16:40:42.426 PDT
tid=0x110] CacheClientNotifier: Keeping proxy for durable client named client-9
for 300 seconds
CacheClientProxy[identity(192.168.1.4(client:36729:loner):59887:9507e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-9;
timeout=300]); port=59892; primary=true; version=GEODE 1.11.0].
[info 2019/10/09 16:40:42.413 PDT tid=0x6e]
CacheClientProxy[identity(192.168.1.4(client:36729:loner):59887:9507e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-9;
timeout=300]); port=59892; primary=true; version=GEODE 1.11.0] : Pausing
processing
{noformat}
Sometimes, the logging looks like: (with log-level=fine):
{noformat}
[info 2019/10/09 16:40:42.429 PDT tid=0x60]
CacheClientProxy[identity(192.168.1.4(client:36717:loner):59851:3301e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-5;
timeout=300]); port=59856; primary=true; version=GEODE 1.11.0] : Pausing
processing
[debug 2019/10/09 16:40:42.428 PDT
tid=0x102] CacheClientNotifier: Not keeping proxy for non-durable client:
CacheClientProxy[identity(192.168.1.4(client:36717:loner):59851:3301e5b2:client,connection=2,durableAttributes=DurableClientAttributes[id=client-5;
timeout=300]); port=59856; primary=true; version=GEODE 1.11.0]
{noformat}
On one hand, the Client Message Dispatcher is pausing, but on the other hand,
the CacheClientProxy is not being kept.
Thats because of this RejectedExecutionException thrown attempting to
asynchronously close the CacheClientProxy's socket:
{noformat}
java.util.concurrent.RejectedExecutionException
at
java.base/java.util.concurrent.ForkJoinPool.externalPush(ForkJoinPool.java:1880)
at
java.base/java.util.concurrent.ForkJoinPool.externalSubmit(ForkJoinPool.java:1921)
at
java.base/java.util.concurrent.ForkJoinPool.submit(ForkJoinPool.java:2497)
at
java.base/java.util.concurrent.ForkJoinPool.submit(ForkJoinPool.java:178)
at
org.apache.geode.internal.net.SocketCloser.asyncExecute(SocketCloser.java:163)
at
org.apache.geode.internal.net.SocketCloser.asyncClose(SocketCloser.java:191)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeSocket(CacheClientProxy.java:955)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeTransientFields(CacheClientProxy.java:963)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.pauseDispatching(CacheClientProxy.java:839)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.close(CacheClientProxy.java:788)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.closeDeadProxies(CacheClientNotifier.java:1563)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.unregisterClient(CacheClientNotifier.java:567)
at
org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitor.unregisterClient(ClientHealthMonitor.java:255)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:961)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:882)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1223)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:674)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
This JDK11 stack shows the ForkJoinPool in a closed state.
Thats because each CacheClientProxy closes its SocketCloser executor here:
{noformat}
[warn 2019/10/09 16:55:36.611 PDT
tid=0x46] XXX SocketCloser.releaseResourcesForAddress address=192.168.1.4;
executorService=java.util.concurrent.ForkJoinPool@15099e74[Running, parallelism
= 1, size = 1, active = 0, running = 0, steals = 1, tasks = 0, submissions = 0]
java.lang.Exception
at
[jira] [Assigned] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-7026: Assignee: Kirk Lund > LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles > fails on Windows > - > > Key: GEODE-7026 > URL: https://issues.apache.org/jira/browse/GEODE-7026 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Donal Evans >Assignee: Kirk Lund >Priority: Major > Labels: IntegrationTest, Windows, flaky > > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681] > org.awaitility.core.ConditionTimeoutException: Assertion condition defined > as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase > expected:<[online]> but was:<[not responding]> within 300 seconds. > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682] > > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683] > Caused by: > [ > |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684] > org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]> > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-6990) Implement Configuration Options for Method Authorizer
[
https://issues.apache.org/jira/browse/GEODE-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-6990:
--
Assignee: Donal Evans
> Implement Configuration Options for Method Authorizer
> -
>
> Key: GEODE-6990
> URL: https://issues.apache.org/jira/browse/GEODE-6990
> Project: Geode
> Issue Type: New Feature
> Components: configuration
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
> Labels: GeodeCommons
>
> Create a new {{QueryServiceConfig}} element at the {{CacheConfig}} level to
> contain any configuration related to the query service, including the custom
> {{MethodInvocationAuthorizer}}.
> The resulting XML element should be as follows:
> {noformat}
>
>
>MyClass
>
> stringValue
>
>
>
> {noformat}
> Instead of modifying the core {{cache-1.0.xsd}}, add another independent
> {{xsd}} file as an extension of the cache’s configuration. An example of how
> to do this can be seen in
> [{{jdbc-1.0.xsd}}|https://github.com/apache/geode/blob/rel/v1.9.0/geode-connectors/src/main/resources/META-INF/schemas/geode.apache.org/schema/jdbc/jdbc-1.0.xsd].
> This new configuration element and its properties should be stored and
> retrieved through the cluster configuration service. For more details
> regarding the interactions with the cluster configuration service see [For
> extension developers: How to Add Elements Managed by Cluster Configuration
> Service|https://cwiki.apache.org/confluence/display/GEODE/For+extension+developers%3A+How+to+Add+Elements+Managed+by+Cluster+Configuration+Service].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-5442) Add search to http://geode.apache.org/docs/guide
[ https://issues.apache.org/jira/browse/GEODE-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-5442. - Resolution: Duplicate > Add search to http://geode.apache.org/docs/guide > > > Key: GEODE-5442 > URL: https://issues.apache.org/jira/browse/GEODE-5442 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Nick Vallely >Priority: Major > > There is no clear way to search through documentation on this site which > makes it difficult to find specific topics I might be interested in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7283) OQL Method Authorizer in Query Execution Context
[
https://issues.apache.org/jira/browse/GEODE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos reassigned GEODE-7283:
-
Assignee: Juan Ramos
> 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
>Assignee: 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)
[jira] [Updated] (GEODE-7283) OQL Method Authorizer in Query Execution Context
[
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
[jira] [Created] (GEODE-7283) OQL Method Authorizer in Query Execution Context
Juan Ramos created GEODE-7283:
-
Summary: 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
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}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7283) OQL Method Authorizer in Query Execution Context
[
https://issues.apache.org/jira/browse/GEODE-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7283:
--
Labels: GeodeCommons (was: )
> 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: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}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-2888) user guide: REST API Region Endpoints use 'gemfire-api' in their names
[ https://issues.apache.org/jira/browse/GEODE-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-2888: Labels: pull-request-available (was: ) > user guide: REST API Region Endpoints use 'gemfire-api' in their names > --- > > Key: GEODE-2888 > URL: https://issues.apache.org/jira/browse/GEODE-2888 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The name 'gemfire-api' should be replaced by 'geode' in the Region Endpoints > section of the manual. See > http://geode.apache.org/docs/guide/11/rest_apps/rest_regions.html and its > subsections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-2888) user guide: REST API Region Endpoints use 'gemfire-api' in their names
[ https://issues.apache.org/jira/browse/GEODE-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-2888: --- Assignee: Alberto Bustamante Reyes > user guide: REST API Region Endpoints use 'gemfire-api' in their names > --- > > Key: GEODE-2888 > URL: https://issues.apache.org/jira/browse/GEODE-2888 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Major > > The name 'gemfire-api' should be replaced by 'geode' in the Region Endpoints > section of the manual. See > http://geode.apache.org/docs/guide/11/rest_apps/rest_regions.html and its > subsections. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6987) Implement RegExMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947507#comment-16947507 ] ASF subversion and git services commented on GEODE-6987: Commit 915e119343aeae7bb7e99892a6c02196adde3cdb in geode's branch refs/heads/develop from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=915e119 ] GEODE-6987: Implement RegExMethodAuthorizer (#4123) - Made the class final, immutable and thread safe. - Added comprehensive javadocs to the class and its methods. - Added several unit tests for the class and all public methods. > Implement RegExMethodAuthorizer > --- > > Key: GEODE-6987 > URL: https://issues.apache.org/jira/browse/GEODE-6987 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Time Spent: 1.5h > Remaining Estimate: 0h > > Implement the [RegExMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RegExMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6987) Implement RegExMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-6987. --- Fix Version/s: 1.11.0 Resolution: Fixed > Implement RegExMethodAuthorizer > --- > > Key: GEODE-6987 > URL: https://issues.apache.org/jira/browse/GEODE-6987 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan Ramos >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > Fix For: 1.11.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Implement the [RegExMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RegExMethodAuthorizer] > class. > * Make sure the class is immutable and thread safe. > * Implement unit tests for the class and all of its methods. > * Add comprehensive and clear documentation to the class and all its public > methods so customers can use it without leaving their IDE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
