[jira] [Updated] (GEODE-4993) GatewaySender connection stats are captured but not stored
[
https://issues.apache.org/jira/browse/GEODE-4993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey updated GEODE-4993:
-
Component/s: statistics
> GatewaySender connection stats are captured but not stored
> --
>
> Key: GEODE-4993
> URL: https://issues.apache.org/jira/browse/GEODE-4993
> Project: Geode
> Issue Type: Improvement
> Components: statistics, wan
>Reporter: Barry Oglesby
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Attachments: geode-4993.diff
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The GatewaySender connection stats are captured but not stored in the gfs
> file. a GatewaySenderEventRemoteDispatcher causes ConnectionStats to be
> created when its connection is created. For some reason, these are saved to a
> DummyStatisticsFactory (which causes them not to be saved):
> {noformat}
> if (pool.getGatewaySender() != null) {
> stats = new ConnectionStats(new DummyStatisticsFactory(), statName,
> this.poolStats);
> }
> {noformat}
> If something like this were done instead, then those statistics would be
> saved in the gfs file under an appropriate name:
> {noformat}
> if (pool.getGatewaySender() != null) {
> String statName = pool.getGatewaySender().getId() + "-" +
> location.toString();
> stats = new ConnectionStats(ds, "GatewaySender", statName, this.poolStats);
> }
> public ConnectionStats(StatisticsFactory factory, String prefix, String name,
> PoolStats poolStats/* , GatewayStats gatewayStats */) {
> this.stats = factory.createAtomicStatistics(type, prefix + "Stats-" + name);
> this.sendStats = factory.createAtomicStatistics(sendType, prefix +
> "SendStats-" + name);
> this.poolStats = poolStats;
> }
> {noformat}
> The kinds of stats tracked by the ConnectionStats include:
> - connections
> - sentBytes
> - receivedBytes
> Here is a stack trace showing where the ConnectionStats are created:
> {noformat}
> java.lang.Exception: Stack trace
> at java.lang.Thread.dumpStack(Thread.java:1329)
> at
> org.apache.geode.cache.client.internal.ConnectionStats.(ConnectionStats.java:1716)
> at
> org.apache.geode.cache.client.internal.EndpointManagerImpl.getStats(EndpointManagerImpl.java:225)
> at
> org.apache.geode.cache.client.internal.EndpointManagerImpl.referenceEndpoint(EndpointManagerImpl.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:124)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:137)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:259)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:242)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:910)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:398)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.getConnection(GatewaySenderEventRemoteDispatcher.java:331)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher._dispatchBatch(GatewaySenderEventRemoteDispatcher.java:208)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.dispatchBatch(GatewaySenderEventRemoteDispatcher.java:157)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:610)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1051)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-6982) The statusMessage field in the Cluster Management Service response needs more editing
[ https://issues.apache.org/jira/browse/GEODE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898392#comment-16898392 ] ASF subversion and git services commented on GEODE-6982: Commit 080d5f486eb645a4a90da934c179faf39dc34be0 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=080d5f4 ] GEODE-6982: standardize/improve CMS status/error messages (#3875) * GEODE-6982: standardize/improve CMS status/error messages Co-authored-by: Joris Melchior Co-authored-by: Darrel Schneider > The statusMessage field in the Cluster Management Service response needs more > editing > - > > Key: GEODE-6982 > URL: https://issues.apache.org/jira/browse/GEODE-6982 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Per docs feedback, for those statusMessages shown on the twiki page: > https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API, these > following improvement could be made: > You can find all these following statusMessage on the twiki page in order: > 1. start with capital letter, > 2 end with a period, > 3. spell out configuration. > 4. no mention of “Cache Element” in ""cache element Foo already exists.", > 5: "Region name is required." instead of "Name of the region has to be > specified.", > 6: remove hyphen between “double-underscore” > 7 "user does not have “DATA:MANAGE” permission" instead of "user not > authorized for DATA:MANAGE". > 8 The cluster configuration service is not running. instead of "cluster > persistence service is not running" > 9 region name needs to be consistent use the one without “/”. > 10: Failed to delete region /Foo. Reason: ”, instead of "Failed to delete > region /Foo because of " > 11: include real server name in “server needs to be restarted” -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6982) The statusMessage field in the Cluster Management Service response needs more editing
[ https://issues.apache.org/jira/browse/GEODE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898393#comment-16898393 ] ASF subversion and git services commented on GEODE-6982: Commit 080d5f486eb645a4a90da934c179faf39dc34be0 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=080d5f4 ] GEODE-6982: standardize/improve CMS status/error messages (#3875) * GEODE-6982: standardize/improve CMS status/error messages Co-authored-by: Joris Melchior Co-authored-by: Darrel Schneider > The statusMessage field in the Cluster Management Service response needs more > editing > - > > Key: GEODE-6982 > URL: https://issues.apache.org/jira/browse/GEODE-6982 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Per docs feedback, for those statusMessages shown on the twiki page: > https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API, these > following improvement could be made: > You can find all these following statusMessage on the twiki page in order: > 1. start with capital letter, > 2 end with a period, > 3. spell out configuration. > 4. no mention of “Cache Element” in ""cache element Foo already exists.", > 5: "Region name is required." instead of "Name of the region has to be > specified.", > 6: remove hyphen between “double-underscore” > 7 "user does not have “DATA:MANAGE” permission" instead of "user not > authorized for DATA:MANAGE". > 8 The cluster configuration service is not running. instead of "cluster > persistence service is not running" > 9 region name needs to be consistent use the one without “/”. > 10: Failed to delete region /Foo. Reason: ”, instead of "Failed to delete > region /Foo because of " > 11: include real server name in “server needs to be restarted” -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6982) The statusMessage field in the Cluster Management Service response needs more editing
[ https://issues.apache.org/jira/browse/GEODE-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-6982. - Resolution: Fixed Fix Version/s: 1.10.0 > The statusMessage field in the Cluster Management Service response needs more > editing > - > > Key: GEODE-6982 > URL: https://issues.apache.org/jira/browse/GEODE-6982 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Per docs feedback, for those statusMessages shown on the twiki page: > https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API, these > following improvement could be made: > You can find all these following statusMessage on the twiki page in order: > 1. start with capital letter, > 2 end with a period, > 3. spell out configuration. > 4. no mention of “Cache Element” in ""cache element Foo already exists.", > 5: "Region name is required." instead of "Name of the region has to be > specified.", > 6: remove hyphen between “double-underscore” > 7 "user does not have “DATA:MANAGE” permission" instead of "user not > authorized for DATA:MANAGE". > 8 The cluster configuration service is not running. instead of "cluster > persistence service is not running" > 9 region name needs to be consistent use the one without “/”. > 10: Failed to delete region /Foo. Reason: ”, instead of "Failed to delete > region /Foo because of " > 11: include real server name in “server needs to be restarted” -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6995) Use the Correct MethodInvocationAuthorizer
[
https://issues.apache.org/jira/browse/GEODE-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6995:
-
Labels: GeodeCommons (was: )
> Use the Correct MethodInvocationAuthorizer
> --
>
> Key: GEODE-6995
> URL: https://issues.apache.org/jira/browse/GEODE-6995
> Project: Geode
> Issue Type: New Feature
> Components: configuration, querying
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Modify the {{DefaultQueryService}} class to
> [instantiate|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L117-L131]
> the required {{MethodInvocationAuthorizer}} obtained from the cluster
> configuration service, none {{MethodInvocationAuthorizer}} at all, or the
> default {{RestrictedMethodAuthorizer}}, depending on the options configured
> by the user.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (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
]
Charlie Black updated GEODE-6990:
-
Labels: GeodeCommons (was: )
> 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 José Ramos Cassella
>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
(v7.6.14#76016)
[jira] [Updated] (GEODE-6993) Documentation for alter query-service command
[ https://issues.apache.org/jira/browse/GEODE-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-6993: - Labels: GeodeCommons (was: ) > Documentation for alter query-service command > - > > Key: GEODE-6993 > URL: https://issues.apache.org/jira/browse/GEODE-6993 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Juan José Ramos Cassella >Priority: Major > Labels: GeodeCommons > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6992) Deprecate allowUntrustedMethodInvocation System Property
[
https://issues.apache.org/jira/browse/GEODE-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6992:
-
Labels: GeodeCommons (was: )
> Deprecate allowUntrustedMethodInvocation System Property
>
>
> Key: GEODE-6992
> URL: https://issues.apache.org/jira/browse/GEODE-6992
> Project: Geode
> Issue Type: New Feature
> Components: configuration
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Deprecate the system property
> {{gemfire.QueryService.allowUntrustedMethodInvocation}}.
> Register a {{warning}} message on the logs whenever the member detects that
> the property is being used so our users are aware of the deprecation.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6991) Create AlterQueryService GFSH Command
[
https://issues.apache.org/jira/browse/GEODE-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6991:
-
Labels: GeodeCommons (was: )
> Create AlterQueryService GFSH Command
> -
>
> Key: GEODE-6991
> URL: https://issues.apache.org/jira/browse/GEODE-6991
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> *As a* Geode user
> *I want to* configure several aspects of the query service
> *so that I can* change the method invocation authorizer.
> The _Method Invocation Authorizer_ should be configurable / exchangeable in
> runtime (it doesn’t need to be an instantaneous update, eventual consistency
> is tolerable) and *there can only be one authorizer configured per cluster:*
> {{alter query-service
> --method-authorizer=test.Authorizer\{'param':'value'\}}}.
> Add Unit, Integration and Distributed tests for the new command.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6994) Documentation for OQL Method Invocation Security
[
https://issues.apache.org/jira/browse/GEODE-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6994:
-
Labels: GeodeCommons (was: )
> Documentation for OQL Method Invocation Security
>
>
> Key: GEODE-6994
> URL: https://issues.apache.org/jira/browse/GEODE-6994
> Project: Geode
> Issue Type: New Feature
> Components: docs
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Delete the [Method Invocations
> Section|https://github.com/apache/geode/blob/rel/v1.9.0/geode-docs/developing/query_select/the_where_clause.html.md.erb#L238-L262]
> and add a new page, on which detailed documentation should be added about
> the following:
> * The new _OQL Method Invocation Security feature_.
> * How to configure the new _OQL Method Invocation Security feature_.
> * Each Out of Box Implementation: pros, cons and *_security risks_*
> associated with each one (check the table within the
> [Introduction|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Summary]
> for details).
> * Interface {{MethodInvocationAuthorizer}} and how/when the user needs to
> provide its own. Requirement about the thread-safety and performance of the
> implementation.
> * Deprecation of the system property
> {{QueryService.allowUntrustedMethodInvocation}} and how it can be replaced by
> one of the Out of Box Implementations.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6989) Use Caching for Already Authorized Methods
[
https://issues.apache.org/jira/browse/GEODE-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6989:
-
Labels: GeodeCommons (was: )
> Use Caching for Already Authorized Methods
> --
>
> Key: GEODE-6989
> URL: https://issues.apache.org/jira/browse/GEODE-6989
> Project: Geode
> Issue Type: New Feature
> Components: querying
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> We already
> [cache|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/CompiledOperation.java#L267-L285]
> created instances of {{MethodDispatch}} to avoid creating them for every
> query. Modify the {{MethodDispatch}} class to remember whether the method was
> allowed by a previous invocation, preventing further calls to the respective
> {{authorizer}} if it was.
> We also
> [cache|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/AttributeDescriptor.java#L148-L170]
> within the {{AttributeDescriptor}} class the member already read by
> reflection for a particular attribute to avoid doing it again and again in
> every query. Modify the {{AttributeDescriptor}} class to remember whether the
> accessor method was allowed by a previous invocation, preventing further
> calls to the respective {{authorizer}} if it was.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-6987) Implement RegexBasedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-6987: - Labels: GeodeCommons (was: ) > Implement RegexBasedMethodAuthorizer > > > Key: GEODE-6987 > URL: https://issues.apache.org/jira/browse/GEODE-6987 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan José Ramos Cassella >Priority: Major > Labels: GeodeCommons > > Implement the [RegexBasedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RegexBasedMethodAuthorizer] > 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 (v7.6.14#76016)
[jira] [Updated] (GEODE-6988) Implement JavaBeanAccessorBasedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-6988: - Labels: GeodeCommons (was: ) > Implement JavaBeanAccessorBasedMethodAuthorizer > --- > > Key: GEODE-6988 > URL: https://issues.apache.org/jira/browse/GEODE-6988 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan José Ramos Cassella >Priority: Major > Labels: GeodeCommons > > Implement the [JavaBeanAccessorBasedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-JavaBeanAccessorBasedMethodAuthorizer] > 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 (v7.6.14#76016)
[jira] [Updated] (GEODE-6986) Implement GeodeBasedMethodAuthorizer
[ https://issues.apache.org/jira/browse/GEODE-6986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-6986: - Labels: GeodeCommons (was: ) > Implement GeodeBasedMethodAuthorizer > > > Key: GEODE-6986 > URL: https://issues.apache.org/jira/browse/GEODE-6986 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Juan José Ramos Cassella >Priority: Major > Labels: GeodeCommons > > Implement the [GeodeBasedMethodAuthorizer > |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-GeodeBasedMethodAuthorizer] > 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 (v7.6.14#76016)
[jira] [Updated] (GEODE-6983) Epic for OQL Method Invocation Security
[ https://issues.apache.org/jira/browse/GEODE-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-6983: - Summary: Epic for OQL Method Invocation Security (was: Epic OQL Method Invocation Security) > Epic for OQL Method Invocation Security > --- > > Key: GEODE-6983 > URL: https://issues.apache.org/jira/browse/GEODE-6983 > Project: Geode > Issue Type: New Feature > Components: querying, security >Reporter: Juan José Ramos Cassella >Priority: Major > > Top level ticket to implement the [OQL Method Security > Proposal|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security]. > Any deviation that might arise during the actual implementation should be > throughly documented under the [Errata > Section|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Errata]. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
[ https://issues.apache.org/jira/browse/GEODE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-7042: Assignee: Aaron Lindsey > Wait until all startup tasks complete to update server status as "online" > - > > Key: GEODE-7042 > URL: https://issues.apache.org/jira/browse/GEODE-7042 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > > Currently, the server status is set to "online" before all of the startup > tasks have completed. This tells users incorrect facts about the system and > its availability. > *Scenario:* > Given a server has just been started > When the following threads have completed: > [Async] [Optional] Begin redundancy recovery > [Async] [Optional] Begin recovery of values from disk > And when the synchronous thread of .start() for the ServerLauncher that > started the server completes without exception > Then the 'status' bit of the ServerLauncher should be set to 'online' > (currently this is set to online regardless of Async processes) > *Notes:* > GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
[ https://issues.apache.org/jira/browse/GEODE-7042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey updated GEODE-7042: - Labels: observability (was: ) > Wait until all startup tasks complete to update server status as "online" > - > > Key: GEODE-7042 > URL: https://issues.apache.org/jira/browse/GEODE-7042 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: observability > > Currently, the server status is set to "online" before all of the startup > tasks have completed. This tells users incorrect facts about the system and > its availability. > *Scenario:* > Given a server has just been started > When the following threads have completed: > [Async] [Optional] Begin redundancy recovery > [Async] [Optional] Begin recovery of values from disk > And when the synchronous thread of .start() for the ServerLauncher that > started the server completes without exception > Then the 'status' bit of the ServerLauncher should be set to 'online' > (currently this is set to online regardless of Async processes) > *Notes:* > GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"
Aaron Lindsey created GEODE-7042: Summary: Wait until all startup tasks complete to update server status as "online" Key: GEODE-7042 URL: https://issues.apache.org/jira/browse/GEODE-7042 Project: Geode Issue Type: Improvement Reporter: Aaron Lindsey Currently, the server status is set to "online" before all of the startup tasks have completed. This tells users incorrect facts about the system and its availability. *Scenario:* Given a server has just been started When the following threads have completed: [Async] [Optional] Begin redundancy recovery [Async] [Optional] Begin recovery of values from disk And when the synchronous thread of .start() for the ServerLauncher that started the server completes without exception Then the 'status' bit of the ServerLauncher should be set to 'online' (currently this is set to online regardless of Async processes) *Notes:* GFSH utilizes this 'online' status to return from the 'start server' command. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6985) Implement RestrictedMethodAuthorizer
[
https://issues.apache.org/jira/browse/GEODE-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6985:
-
Labels: GeodeCommons (was: )
> Implement RestrictedMethodAuthorizer
>
>
> Key: GEODE-6985
> URL: https://issues.apache.org/jira/browse/GEODE-6985
> Project: Geode
> Issue Type: New Feature
> Components: querying
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Implement the
> [RestrictedMethodAuthorizer|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RestrictedMethodAuthorizer]
> class.
> * Make sure the class is immutable and thread safe.
> * Add two new public methods to the implementation:
> ** {{isAllowedGeodeMethod}}: it should return {{true}} when the {{Method}} on
> the target {{Object}} is considered safe ({{Region.get}},
> {{Region.entrySet}}, {{Region.keySet}}, {{Region.values}},
> {{Region.getEntries}}, {{Region.getValues}}, {{Region.containsKey}},
> {{Region.getKey}} and {{Region.getValue}}), and {{false}} otherwise.
> ** {{isKnownDangerousMethod}}: it should return {{true}} when the {{Method}}
> on the target {{Object}} is known to be a non-safe method. Including but not
> limited to {{getClass}}, which allows the user to execute anything using
> reflection.
> * 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
(v7.6.14#76016)
[jira] [Updated] (GEODE-6984) Publish MethodInvocationAuthorizer and RestrictedMethodInvocationAuthorizer
[
https://issues.apache.org/jira/browse/GEODE-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-6984:
-
Labels: GeodeCommons (was: )
> Publish MethodInvocationAuthorizer and RestrictedMethodInvocationAuthorizer
> ---
>
> Key: GEODE-6984
> URL: https://issues.apache.org/jira/browse/GEODE-6984
> Project: Geode
> Issue Type: New Feature
> Components: querying
>Reporter: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
>
> Move both classes out of the {{internal}} package and make them public. The
> new name for {{RestrictedMethodInvocationAuthorizer}} should be
> {{RestrictedMethodAuthorizer}}.
> Once this ticket is implemented, the {{DefaultQueryService}} should use the
> actual rules and
> [instantiate|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L117-L131]
> the new {{RestrictedMethodAuthorizer}} by default so we can continue
> implementing the rest of the proposal without blocking any releases.
> Add comprehensive and clear documentation to the classes and all methods so
> customers can use and understand them without leaving their IDE.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely updated GEODE-7001: Labels: observability (was: ) > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Labels: observability > Time Spent: 7h 50m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7041) Write Test for FunctionService::OnServers() in New Test Framework
Michael Martell created GEODE-7041: -- Summary: Write Test for FunctionService::OnServers() in New Test Framework Key: GEODE-7041 URL: https://issues.apache.org/jira/browse/GEODE-7041 Project: Geode Issue Type: Improvement Components: native client Reporter: Michael Martell Currently there are no C++ tests for this API. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-7040) Fix checked assertion and connection parameters to 'FunctionReturnsObjectWhichCantBeDeserializedOnServer' test
Blake Bender created GEODE-7040: --- Summary: Fix checked assertion and connection parameters to 'FunctionReturnsObjectWhichCantBeDeserializedOnServer' test Key: GEODE-7040 URL: https://issues.apache.org/jira/browse/GEODE-7040 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender We found, in the course of developing another function execution test, that this one was attempting to connect to the locator on the wrong port, and was thus checking for the wrong exception at the end. Fix is pretty trivial, but it should go in on its own, hence the separate Jira ticket. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala resolved GEODE-7026. Resolution: Duplicate re-opened 6183 > 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 >Priority: Major > Labels: IntegrationTest, Windows > > 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 (v7.6.14#76016)
[jira] [Reopened] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murtuza Boxwala reopened GEODE-6183: We are still seeing instances of this issue occurring specifically on Windows: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/169] [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/174] > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: ci, gfsh >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Fix For: 1.10.0 > > Time Spent: 5.5h > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898226#comment-16898226 ] Kirk Lund commented on GEODE-7026: -- Yes, GEODE-7026 is same as GEODE-6183. > 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 >Priority: Major > Labels: IntegrationTest, Windows > > 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 (v7.6.14#76016)
[jira] [Commented] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898210#comment-16898210 ] ASF subversion and git services commented on GEODE-6973: Commit 181e3a4a465aa9f5e06f39cd1285c94f9bc78600 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=181e3a4 ] GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r… (#3853) * GEODE-6973: Use cachelistener to synchronize typeToId with IdToType region in PeerTypeRegistrationm, then when creating a new json pdxType, no need to look up in IdToType region. This will speed up creating new pdxType. Co-authored-by: Xiaojian Zhou Co-authored-by: Donal Evans > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 3h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou resolved GEODE-6973. -- Resolution: Fixed Fix Version/s: 1.10.0 > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.10.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898211#comment-16898211 ] ASF subversion and git services commented on GEODE-6973: Commit 181e3a4a465aa9f5e06f39cd1285c94f9bc78600 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=181e3a4 ] GEODE-6973: Use cachelistener to synchronize typeToId with IdToType r… (#3853) * GEODE-6973: Use cachelistener to synchronize typeToId with IdToType region in PeerTypeRegistrationm, then when creating a new json pdxType, no need to look up in IdToType region. This will speed up creating new pdxType. Co-authored-by: Xiaojian Zhou Co-authored-by: Donal Evans > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 3h 40m > Remaining Estimate: 0h > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the comparison will have to compare up to 30 fields. If > the idToType region contains 20K entries, A new pdxType will do 20K x 30 > string comparisons before register it. > We found each server maintained a typeToId map, this map is used to check if > the pdxType exists. If exists, it will return the type id without check the > IdToType region. The total number of pdxType did not impact the put > performance if the pdxTypd exists. > The typeToId map is maintained with a d-lock, each time we added a new > pdxType, it will update into the map while still holding the d-lok. So we > believe that the map should be the same as the region in content. If we > cannot find the pdxType in the map, it should not be in the region. We can > skip the iteration of region (which is the root cause of the performance > issue). > Another issue in current code is: when each time a new type come, it will > recreate the map. This is unnecessary and contributes to the slowness too. > We should only create the map during initialize(). > Here are the tests we want to introduce: > 1) a junit test to prove that reorder fields in a big JSON file will not > cause significant hashcode conflicts (<1%) > 2) a junit test to prove that add a index to a field in a big JSON file will > hardly cause hashcode conflicts. > This 2 tests are to prove that hashcode conflict is not the root cause of > linear probing for PDXTypeId. > 3) a junit test to prove that for the cases that hashcode conflict caused by > reordered fields, there will be no hashcode conflicts if using > SORT_JSON_FIELD_NAMES_PROPERTY=true. > 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false > did not impact the performance to add a new pdxType. > 5) a dunit test to create a new pdxType from 2 peer server at the same time. > The test is to prove that the d-lock take effect, one server create the > pdxType, and another server should find the pdxType exists. > Do this test both from server directly and from clients. > 6) Create 2 different objects which ends up with the same hashcode (we can > get the 2 objects from test-1), try to put the 2 objects to create new > pdxType. The 2nd one should also create a new type. It should not be treated > as "found an existing pdxType". -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7033) User Guide - Balance lists in left-hand nav panel
[ https://issues.apache.org/jira/browse/GEODE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898204#comment-16898204 ] ASF subversion and git services commented on GEODE-7033: Commit bf2813cdeb8160c54805794eb508263777c13ba2 in geode's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf2813c ] GEODE-7033: User Guide - Balance lists in left-hand nav panel > User Guide - Balance lists in left-hand nav panel > - > > Key: GEODE-7033 > URL: https://issues.apache.org/jira/browse/GEODE-7033 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > In the source file for the left-hand navigation panel > (geode-book/master_middleman/source/subnavs/geode-subnav.erb, the tags > outnumber the tags 709 to 702. Not sure if this manifests as a visible > error, but it's error-prone for maintenance going forward. Number of opening > tags should match the number of closing tags, as with the pairs " > " and " ". > ``` > 64:subnavs$ grep " 2 > 65:subnavs$ grep " 2 > 66:subnavs$ grep " 125 > 67:subnavs$ grep " 125 > 68:subnavs$ grep " 709 > 69:subnavs$ grep " 702 > ``` > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7033) User Guide - Balance lists in left-hand nav panel
[ https://issues.apache.org/jira/browse/GEODE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898205#comment-16898205 ] ASF subversion and git services commented on GEODE-7033: Commit c349e981934eca9f7f677c026cbeec0ca01cf21f in geode's branch refs/heads/develop from Joey McAllister [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c349e98 ] Merge pull request #3874 from Nordix/feature/GEODE-7033 GEODE-7033: User Guide - Balance lists in left-hand nav panel > User Guide - Balance lists in left-hand nav panel > - > > Key: GEODE-7033 > URL: https://issues.apache.org/jira/browse/GEODE-7033 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > In the source file for the left-hand navigation panel > (geode-book/master_middleman/source/subnavs/geode-subnav.erb, the tags > outnumber the tags 709 to 702. Not sure if this manifests as a visible > error, but it's error-prone for maintenance going forward. Number of opening > tags should match the number of closing tags, as with the pairs " > " and " ". > ``` > 64:subnavs$ grep " 2 > 65:subnavs$ grep " 2 > 66:subnavs$ grep " 125 > 67:subnavs$ grep " 125 > 68:subnavs$ grep " 709 > 69:subnavs$ grep " 702 > ``` > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7033) User Guide - Balance lists in left-hand nav panel
[ https://issues.apache.org/jira/browse/GEODE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898206#comment-16898206 ] ASF subversion and git services commented on GEODE-7033: Commit c349e981934eca9f7f677c026cbeec0ca01cf21f in geode's branch refs/heads/develop from Joey McAllister [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c349e98 ] Merge pull request #3874 from Nordix/feature/GEODE-7033 GEODE-7033: User Guide - Balance lists in left-hand nav panel > User Guide - Balance lists in left-hand nav panel > - > > Key: GEODE-7033 > URL: https://issues.apache.org/jira/browse/GEODE-7033 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > In the source file for the left-hand navigation panel > (geode-book/master_middleman/source/subnavs/geode-subnav.erb, the tags > outnumber the tags 709 to 702. Not sure if this manifests as a visible > error, but it's error-prone for maintenance going forward. Number of opening > tags should match the number of closing tags, as with the pairs " > " and " ". > ``` > 64:subnavs$ grep " 2 > 65:subnavs$ grep " 2 > 66:subnavs$ grep " 125 > 67:subnavs$ grep " 125 > 68:subnavs$ grep " 709 > 69:subnavs$ grep " 702 > ``` > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Comment Edited] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898201#comment-16898201 ] Murtuza Boxwala edited comment on GEODE-7026 at 8/1/19 5:02 PM: [~klund] is this the same as GEODE-6183? https://issues.apache.org/jira/browse/GEODE-6183 [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/174] was (Author: mboxwala): [~klund] is this the same as GEODE-6183? https://issues.apache.org/jira/browse/GEODE-6183 > 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 >Priority: Major > Labels: IntegrationTest, Windows > > 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 (v7.6.14#76016)
[jira] [Commented] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows
[ https://issues.apache.org/jira/browse/GEODE-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898201#comment-16898201 ] Murtuza Boxwala commented on GEODE-7026: [~klund] is this the same as GEODE-6183? https://issues.apache.org/jira/browse/GEODE-6183 > 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 >Priority: Major > Labels: IntegrationTest, Windows > > 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 (v7.6.14#76016)
[jira] [Resolved] (GEODE-7004) Optimize ResourcePermission constructor
[
https://issues.apache.org/jira/browse/GEODE-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett resolved GEODE-7004.
-
Resolution: Fixed
> Optimize ResourcePermission constructor
>
>
> Key: GEODE-7004
> URL: https://issues.apache.org/jira/browse/GEODE-7004
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: performance
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PartitionedPutBenchmark with Security Manager enabled shows a performance
> degradation:
> {noformat}
> org.apache.geode.benchmark.tests.PartitionedPutBenchmark
> average ops/second Baseline:313077.71 Test:303114.88
> Difference: -3.2%
>ops/second standard error Baseline: 714.84 Test: 511.86
> Difference: -28.4%
>ops/second standard deviation Baseline: 12360.75 Test: 8850.96
> Difference: -28.4%
> YS 99th percentile latency Baseline: 2901.00 Test: 2802.00
> Difference: -3.4%
> median latency Baseline: 1586175.00 Test: 1613823.00
> Difference: +1.7%
> 90th percentile latency Baseline: 2289663.00 Test: 2303999.00
> Difference: +0.6%
> 99th percentile latency Baseline: 3213311.00 Test: 3289087.00
> Difference: +2.4%
>99.9th percentile latency Baseline: 72220671.00 Test: 61636607.00
> Difference: -14.7%
> average latency Baseline: 1838420.24 Test: 1898668.38
> Difference: +3.3%
> latency standard deviation Baseline: 3840098.38 Test: 3827737.37
> Difference: -0.3%
> latency standard error Baseline: 396.30 Test: 401.43
> Difference: +1.3%
> {noformat}
> In stats, we noticed a higher CPU utilization and less puts.
>
> When Security Manager is enabled, every put operation calls
> IntegratedSecurityService.authorize method, which creates new
> ResourcePermission object. Every execution of ResourcePermission constructor
> takes 5 ms. With the optimization, ResourcePermission constructor execution
> takes less than 0.1 ms.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GEODE-6804) Tab completion does not work when specifying path for --jar argument in gfsh
[ https://issues.apache.org/jira/browse/GEODE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-6804. - Resolution: Fixed > Tab completion does not work when specifying path for --jar argument in gfsh > > > Key: GEODE-6804 > URL: https://issues.apache.org/jira/browse/GEODE-6804 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ryan McMahon >Assignee: Darrel Schneider >Priority: Major > Labels: gfsh, management, starter > Fix For: 1.10.0 > > Attachments: Screen Shot 2019-05-24 at 9.28.29 AM.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > When attempting to use tab completion for the path in the `–jar` argument in > gfsh, instead of completing the path it adds the next argument (`–dir` in my > case). It would be nice if `–jar` path supported tab completion. > !Screen Shot 2019-05-24 at 9.28.29 AM.png! -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-7024) CMS Java API on locator and client should have similar error handling
[ https://issues.apache.org/jira/browse/GEODE-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-7024. - Resolution: Fixed Fix Version/s: 1.10.0 > CMS Java API on locator and client should have similar error handling > - > > Key: GEODE-7024 > URL: https://issues.apache.org/jira/browse/GEODE-7024 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.10.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The two implementations of ClusterManagementService should behave similarly > in how errors are handled. Currently calls to ClientClusterManagementService > return a ClusterManagementResult bearing the status of the call, while calls > to LocatorClusterManagementService are declared to return the same status > wrapper, but in fact may often throw a Java exception instead. > The goal is to be able to code to the ClusterManagementService interface. > Therefore to be consistent, ClientClusterManagementService should be changed > to raise error statuses as Java exceptions, just as a Java developer would > expect. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7039) Server recovery severely degrades client read traffic (no SingleHop no TX) on redundant partitioned regions
[ https://issues.apache.org/jira/browse/GEODE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-7039: --- Assignee: Mario Ivanac > Server recovery severely degrades client read traffic (no SingleHop no TX) on > redundant partitioned regions > --- > > Key: GEODE-7039 > URL: https://issues.apache.org/jira/browse/GEODE-7039 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > Client not using single hop nor transactions is experiencing severe > throttling from the cluster when getting data from a partitioned region while > server hosting one of the redundant buckets is recovering (in the process of > image recovery). Get operation that have not landed on a server hosting the > bucket will be proxied to other members that do have the bucket in a random > fashion. This random picking has the nasty consequence that chosen server > might be the one recovering now and the bucket is not yet ready > (BucketNotFoundException), which means local server will handle > ForceReattemptException by sleeping 100ms before another (random) attempt. > This sleeping is devasteting for throughput observed by the client. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-7033) User Guide - Balance lists in left-hand nav panel
[ https://issues.apache.org/jira/browse/GEODE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-7033: Labels: pull-request-available (was: ) > User Guide - Balance lists in left-hand nav panel > - > > Key: GEODE-7033 > URL: https://issues.apache.org/jira/browse/GEODE-7033 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > In the source file for the left-hand navigation panel > (geode-book/master_middleman/source/subnavs/geode-subnav.erb, the tags > outnumber the tags 709 to 702. Not sure if this manifests as a visible > error, but it's error-prone for maintenance going forward. Number of opening > tags should match the number of closing tags, as with the pairs " > " and " ". > ``` > 64:subnavs$ grep " 2 > 65:subnavs$ grep " 2 > 66:subnavs$ grep " 125 > 67:subnavs$ grep " 125 > 68:subnavs$ grep " 709 > 69:subnavs$ grep " 702 > ``` > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-7033) User Guide - Balance lists in left-hand nav panel
[ https://issues.apache.org/jira/browse/GEODE-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-7033: --- Assignee: Alberto Bustamante Reyes > User Guide - Balance lists in left-hand nav panel > - > > Key: GEODE-7033 > URL: https://issues.apache.org/jira/browse/GEODE-7033 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > In the source file for the left-hand navigation panel > (geode-book/master_middleman/source/subnavs/geode-subnav.erb, the tags > outnumber the tags 709 to 702. Not sure if this manifests as a visible > error, but it's error-prone for maintenance going forward. Number of opening > tags should match the number of closing tags, as with the pairs " > " and " ". > ``` > 64:subnavs$ grep " 2 > 65:subnavs$ grep " 2 > 66:subnavs$ grep " 125 > 67:subnavs$ grep " 125 > 68:subnavs$ grep " 709 > 69:subnavs$ grep " 702 > ``` > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6933) Gateway sender alert-threshold not working
[
https://issues.apache.org/jira/browse/GEODE-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-6933:
--
Fix Version/s: 1.10.0
> Gateway sender alert-threshold not working
> --
>
> Key: GEODE-6933
> URL: https://issues.apache.org/jira/browse/GEODE-6933
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.10.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> When alert-threshold function is activated in gateway senders (set
> alert-threshold to non zero value),
> event is never raised, for entries which are in queue longer than
> alert-threshold value.
>
> Printout from logs:
> Monitor = GatewaySenderMXBeanMonitor descriptor =
> eventsExceedingAlertThreshold And value = 0
>
> It seams that reporting of events which exceed alert threshold (class
> AbstractGatewaySenderEventProcessor), is working only if dispatcher is
> instance of GatewaySenderEventCallbackDispatcher.
> With deeper analysis, I got to conclusion that for GatewaySender - dispatcher
> is instance of {color:#629755}GatewaySenderEventRemoteDispatcher.{color}
> {color:#ff}So this function is only working for
> {color}{color:#808080}AsyncEventQueue, for which dispatcher is instance of
> GatewaySenderEventCallbackDispatcher.{color}
>
> {color:#808080}The other problem is that _getEventsExceedingAlertThreshold()
> method of_ _GatewaySenderMBean is always returning hardcoded value
> (0)._{color}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (GEODE-3632) LocalDataSet.getAll -- NotAuthorizedExceptions should be thrown, not only logged.
[ https://issues.apache.org/jira/browse/GEODE-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-3632: -- Labels: needs-review pull-request-available (was: needs-review pull-request-available region) > LocalDataSet.getAll -- NotAuthorizedExceptions should be thrown, not only > logged. > - > > Key: GEODE-3632 > URL: https://issues.apache.org/jira/browse/GEODE-3632 > Project: Geode > Issue Type: Bug > Components: core, security >Reporter: Patrick Rhomberg >Assignee: Mario Kevo >Priority: Major > Labels: needs-review, pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Refer to the geode-example clientSecurity, currently in [pull request > 17](https://github.com/apache/geode-examples/pull/17). Unauthorized getAll > method calls log the lack of authorization but do not rethrow the exception. > This is inconsistent with behavior of put, putAll, and get. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
