[jira] [Commented] (GEODE-6369) Cache-creation failure after a successful auto-reconnect causes subsequent NPE
[ https://issues.apache.org/jira/browse/GEODE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405514#comment-17405514 ] Geode Integration commented on GEODE-6369: -- Seen in [windows-unit-test-openjdk8 #146|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/146] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-results/test/1630014649/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0442/test-artifacts/1630014649/windows-unittestfiles-openjdk8-1.15.0-build.0442.tgz]. > Cache-creation failure after a successful auto-reconnect causes subsequent NPE > -- > > Key: GEODE-6369 > URL: https://issues.apache.org/jira/browse/GEODE-6369 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If your server auto-reconnects but there is a problem recreating the cache > the JGroups channel used for auto-reconnect is closed. This causes an NPE > when the server makes another auto-reconnect attempt. > The server should instead just log the problem and shut down since future > attempts to recreate the cache will probably run into the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6369) Cache-creation failure after a successful auto-reconnect causes subsequent NPE
[ https://issues.apache.org/jira/browse/GEODE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405513#comment-17405513 ] Geode Integration commented on GEODE-6369: -- Seen in [windows-unit-test-openjdk11 #147|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/147] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-results/test/1630020537/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0443/test-artifacts/1630020537/windows-unittestfiles-openjdk11-1.15.0-build.0443.tgz]. > Cache-creation failure after a successful auto-reconnect causes subsequent NPE > -- > > Key: GEODE-6369 > URL: https://issues.apache.org/jira/browse/GEODE-6369 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If your server auto-reconnects but there is a problem recreating the cache > the JGroups channel used for auto-reconnect is closed. This causes an NPE > when the server makes another auto-reconnect attempt. > The server should instead just log the problem and shut down since future > attempts to recreate the cache will probably run into the same issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9556) GETSET command supported
[ https://issues.apache.org/jira/browse/GEODE-9556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner updated GEODE-9556: Labels: redis (was: ) > GETSET command supported > > > Key: GEODE-9556 > URL: https://issues.apache.org/jira/browse/GEODE-9556 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Priority: Major > Labels: redis > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers for the following command: > * GETSET > *A.C.* > * Unit/integration tests for both Geode and native Redis passing > * DUNIT tests passing > * README/redis_api_for_geode.html.md.erb updated to make command "supported" > _or_ > * Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9556) GETSET command supported
Eric Zoerner created GEODE-9556: --- Summary: GETSET command supported Key: GEODE-9556 URL: https://issues.apache.org/jira/browse/GEODE-9556 Project: Geode Issue Type: New Feature Components: redis Affects Versions: 1.15.0 Reporter: Eric Zoerner Write unit/integration tests that run against both Geode Redis and native Redis, and dunit tests which test multiple concurrent clients accessing different servers for the following command: * GETSET *A.C.* * Unit/integration tests for both Geode and native Redis passing * DUNIT tests passing * README/redis_api_for_geode.html.md.erb updated to make command "supported" _or_ * Stories in the backlog to fix the identified issues (with JIRA tickets) and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9555) the redis commands that increment or decrement using a long do an extra conversion
Darrel Schneider created GEODE-9555: --- Summary: the redis commands that increment or decrement using a long do an extra conversion Key: GEODE-9555 URL: https://issues.apache.org/jira/browse/GEODE-9555 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider The redis commands that increment or decrement using a long end up storing the new value in the RedisData instance as an ascii byte array. They are also required to return that value to the client. When geode's implementation returns the value, it currently does so as a "long" instead of as a "byte[]". This forces the code later on to call Coder.longToBytes again. Since we already have it in the correct form we should return that to the caller so that it can just copy the bytes instead of needing to compute them again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9555) the redis commands that increment or decrement using a long do an extra conversion
[ https://issues.apache.org/jira/browse/GEODE-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9555: --- Assignee: Darrel Schneider > the redis commands that increment or decrement using a long do an extra > conversion > -- > > Key: GEODE-9555 > URL: https://issues.apache.org/jira/browse/GEODE-9555 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > The redis commands that increment or decrement using a long end up storing > the new value in the RedisData instance as an ascii byte array. They are also > required to return that value to the client. When geode's implementation > returns the value, it currently does so as a "long" instead of as a "byte[]". > This forces the code later on to call Coder.longToBytes again. Since we > already have it in the correct form we should return that to the caller so > that it can just copy the bytes instead of needing to compute them again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8044) Move services related to classloader-isolation to geode-common-services.
[ https://issues.apache.org/jira/browse/GEODE-8044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-8044: - Fix Version/s: 1.14.0 > Move services related to classloader-isolation to geode-common-services. > > > Key: GEODE-8044 > URL: https://issues.apache.org/jira/browse/GEODE-8044 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Fix For: 1.14.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dick Cavender updated GEODE-7846: - Fix Version/s: 1.14.0 > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
[ https://issues.apache.org/jira/browse/GEODE-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405504#comment-17405504 ] ASF subversion and git services commented on GEODE-9408: Commit b377e3f808562fdf59d2753a5a58fd9b9d603883 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b377e3f ] GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true (#6663) GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender The logic for removing events from the Serial Gateway Sender queue when an ack for a batch is received from the gateway receiver is implemented by the remove() method of the SerialGatewaySenderQueue class. When the group-transaction-events setting is activated, this logic, needs to act differently if the event was an event peeked to complete a transaction in a batch than if it is an event peeked with the peekAhead method. In the first case, the head key and lastDispatched member must not be updated with the key of the event because that could provoke that events from the queue not yet retrieved are never retrieved. Nevertheless, the head key and lastDispatched member must be updated for a key peeked to complete a transaction (extraPeekedId) when the key with the previous id is removed. This was not being done in some cases by the remove() method and it has been corrected in this PR. Several DUnit test cases have been added to test this fix in a Geode WAN system with a Serial GatewaySender with group-transaction-events set to true. In the test cases, it is verified that no duplicated events are sent by means of checking that incomplete transactions are not sent. Increase default number of retries > Avoid duplicate events sent by Serial Gateway Sender when > group-transaction-events is true > -- > > Key: GEODE-9408 > URL: https://issues.apache.org/jira/browse/GEODE-9408 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is set to true for a serial gateway sender, it > is possible that events that were retrieved from the queue to be added to a > batch in order to complete a transaction are later sent again in another > batch due to a bug in the removal logic of events when the ack for a batch is > received from the receiver. > This situation has been seen when several clients are sending transactions to > a Geode cluster when the events for the transactions sent by the clients are > mixed in the gateway sender queue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9408) Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true
[ https://issues.apache.org/jira/browse/GEODE-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405503#comment-17405503 ] ASF subversion and git services commented on GEODE-9408: Commit b377e3f808562fdf59d2753a5a58fd9b9d603883 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b377e3f ] GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender when group-transaction-events is true (#6663) GEODE-9408: Avoid duplicate events sent by Serial Gateway Sender The logic for removing events from the Serial Gateway Sender queue when an ack for a batch is received from the gateway receiver is implemented by the remove() method of the SerialGatewaySenderQueue class. When the group-transaction-events setting is activated, this logic, needs to act differently if the event was an event peeked to complete a transaction in a batch than if it is an event peeked with the peekAhead method. In the first case, the head key and lastDispatched member must not be updated with the key of the event because that could provoke that events from the queue not yet retrieved are never retrieved. Nevertheless, the head key and lastDispatched member must be updated for a key peeked to complete a transaction (extraPeekedId) when the key with the previous id is removed. This was not being done in some cases by the remove() method and it has been corrected in this PR. Several DUnit test cases have been added to test this fix in a Geode WAN system with a Serial GatewaySender with group-transaction-events set to true. In the test cases, it is verified that no duplicated events are sent by means of checking that incomplete transactions are not sent. Increase default number of retries > Avoid duplicate events sent by Serial Gateway Sender when > group-transaction-events is true > -- > > Key: GEODE-9408 > URL: https://issues.apache.org/jira/browse/GEODE-9408 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is set to true for a serial gateway sender, it > is possible that events that were retrieved from the queue to be added to a > batch in order to complete a transaction are later sent again in another > batch due to a bug in the removal logic of events when the ack for a batch is > received from the receiver. > This situation has been seen when several clients are sending transactions to > a Geode cluster when the events for the transactions sent by the clients are > mixed in the gateway sender queue. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9547: - Component/s: redis > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:WRITE:REDIS_DATA ?? In the future we may provide more fine grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9547: - Labels: redis (was: ) > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: redis > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:WRITE:REDIS_DATA ?? In the future we may provide more fine grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9546: - Component/s: redis > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-username > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used** > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > **When the AUTH command has a single argument (e.g. AUTH xx) the single > argument is interpreted as a password/token and the default Redis user is > used for authentication. When the AUTH command has two arguments (e.g. AUTH > xx yy) the first argument is interpreted as a username and is used > instead of the default Redis user. The second argument is interpreted as a > password. > +Acceptance Criteria+ > > When a SecurityManager is configured, Redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform Redis operations. Until we support ACLS, use of > the AUTH command with more than two arguments is invalid syntax. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9546: - Labels: redis (was: ) > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: redis > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-username > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the user (security-username > property) and the user provided password (security-password property) and > properly handle the AuthenticationFailedException. If the AUTH command was > called without a user the value of compatible-with-redis-user should be used** > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > **When the AUTH command has a single argument (e.g. AUTH xx) the single > argument is interpreted as a password/token and the default Redis user is > used for authentication. When the AUTH command has two arguments (e.g. AUTH > xx yy) the first argument is interpreted as a username and is used > instead of the default Redis user. The second argument is interpreted as a > password. > +Acceptance Criteria+ > > When a SecurityManager is configured, Redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform Redis operations. Until we support ACLS, use of > the AUTH command with more than two arguments is invalid syntax. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9554) Rebalancing a region with multiple redundancy zones can fail
[ https://issues.apache.org/jira/browse/GEODE-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9554: -- Labels: pull-request-available (was: ) > Rebalancing a region with multiple redundancy zones can fail > > > Key: GEODE-9554 > URL: https://issues.apache.org/jira/browse/GEODE-9554 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.4, 1.13.4, 1.14.0, 1.15.0 >Reporter: Mark Hanson >Priority: Major > Labels: pull-request-available > > When attempting to rebalance a region with multiple redundancy zones, the > code does not distinguish between zones when deleting redundant bucket > copies. This can mean that a bucket from a different zone gets deleted > leaving the servers in a state of reduced redundancy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9554) Rebalancing a region with multiple redundancy zones can fail
Mark Hanson created GEODE-9554: -- Summary: Rebalancing a region with multiple redundancy zones can fail Key: GEODE-9554 URL: https://issues.apache.org/jira/browse/GEODE-9554 Project: Geode Issue Type: Bug Components: core Affects Versions: 1.13.4, 1.12.4, 1.14.0, 1.15.0 Reporter: Mark Hanson When attempting to rebalance a region with multiple redundancy zones, the code does not distinguish between zones when deleting redundant bucket copies. This can mean that a bucket from a different zone gets deleted leaving the servers in a state of reduced redundancy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9436) Implement ZREMRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405469#comment-17405469 ] ASF subversion and git services commented on GEODE-9436: Commit 10f5f303636f16bd3a4681d1100f4731ad562c0f in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=10f5f30 ] GEODE-9436: Implement Radish ZREMRANGEBYSCORE command (#6800) - Add iteratorRangeRemove() and removeRange() methods to RedisSortedSet - Add ZRemRangeByScoreExecutor as subclass of ZRangeByScoreExecutor - Add tests for ZREMRANGEBYSCORE Authored-by: Donal Evans > Implement ZREMRANGEBYSCORE Command > -- > > Key: GEODE-9436 > URL: https://issues.apache.org/jira/browse/GEODE-9436 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [ZREMRANGEBYSCORE|https://redis.io/commands/zremrangebyscore] > command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9436) Implement ZREMRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9436. Fix Version/s: 1.15.0 Resolution: Fixed > Implement ZREMRANGEBYSCORE Command > -- > > Key: GEODE-9436 > URL: https://issues.apache.org/jira/browse/GEODE-9436 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [ZREMRANGEBYSCORE|https://redis.io/commands/zremrangebyscore] > command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9464) Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore
[ https://issues.apache.org/jira/browse/GEODE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405456#comment-17405456 ] ASF GitHub Bot commented on GEODE-9464: --- mmartell merged pull request #856: URL: https://github.com/apache/geode-native/pull/856 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore > --- > > Key: GEODE-9464 > URL: https://issues.apache.org/jira/browse/GEODE-9464 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The current Asp.Net sample app uses Steeltoe for discovery and registration > of our sessionstate provider. We need a non-Steeltoe sample as well, since > not everyone uses Steeltoe. > This will be a good test of our NuGet access to the SessionState Core > artifacts and its dependencies. > Note: Ensure that the web application runs on all platforms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9464) Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore
[ https://issues.apache.org/jira/browse/GEODE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405455#comment-17405455 ] ASF subversion and git services commented on GEODE-9464: Commit 597ab211c7182ceab8942816f9adbe49d3af3b8f in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=597ab21 ] GEODE-9464: Add Asp.Net Core session state sample application (#856) * Add AspNetCore GeodeSession Sample * Create region for sessionState in startserver * Add Apache license header > Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore > --- > > Key: GEODE-9464 > URL: https://issues.apache.org/jira/browse/GEODE-9464 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The current Asp.Net sample app uses Steeltoe for discovery and registration > of our sessionstate provider. We need a non-Steeltoe sample as well, since > not everyone uses Steeltoe. > This will be a good test of our NuGet access to the SessionState Core > artifacts and its dependencies. > Note: Ensure that the web application runs on all platforms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7125) Simplify documentation navigation (remove left nav parent links; add in-page TOCs)
[ https://issues.apache.org/jira/browse/GEODE-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-7125: --- Priority: Minor (was: Major) > Simplify documentation navigation (remove left nav parent links; add in-page > TOCs) > -- > > Key: GEODE-7125 > URL: https://issues.apache.org/jira/browse/GEODE-7125 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Joey McAllister >Assignee: Dave Barnes >Priority: Minor > > The Geode user guide uses Bookbinder to create HTML documentation from > markdown files. This ticket is about changing two ways in which Geode > currently uses Bookbinder sub-optimally: > # For listings in the left navigation with submenus, we give the parent > listing a link to a TOC page—e.g., [Prerequisites and Installation > Instructions|[https://geode.apache.org/docs/guide/19/prereq_and_install.html]]. > This isn't inherently bad (though it is somewhat redundant, as the left > navigation also serves this purpose), but when a user visits such a link, the > submenu on the left collapses. _Note:_ _The menu does not collapse when a > user visits a child link in the submenu of these items._ > ** Fix/Improvement: Wherever possible, remove the link from the subnav > parent item (leaving the now-unclickable parent item) and the related TOC > page. If the TOC page contains content beyond a TOC for the child pages, move > that content to an appropriate place within the existing child pages or, if > necessary, create a new page for it. For instance, the information above the > TOC in [Configuring and Running a > Cluster|[https://geode.apache.org/docs/guide/19/configuring/chapter_overview.html]] > could move to a new page at the top of that parent's submenu or, more > likely, to the Overview of the [Cluster Configuration > Service|[https://geode.apache.org/docs/guide/19/configuring/cluster_config/gfsh_persist.html]] > page. > # For left nav listings with submenus where all the pages link to anchors > within a page (instead of to topics on individual pages), Bookbinder provides > an option called "quicklinks" that automatically uses H2 (`##`) and smaller > subheads to create a small, in-page TOC at the top of the page. We currently > disable this functionality. > ** Fix/Improvement: Remove the "no-quicklinks" tags from anchors that we > want to appear in the in-page TOC. Also remove any duplicate links from the > left navigation. (In other words, the in-page TOC will now replace some > navigation functionality currently performed by the left nav, thereby > simplifying the left nav.) For example, see [Managing Heap and Off-heap > Memory|[https://geode.apache.org/docs/guide/19/managing/heap_use/heap_management.html]], > where many (but, notably, not all) of the child links in the left nav lead > to anchors within one page. These can become one new child page/link called > Managing Heap Memory, leaving only Resource Manager Example Configurations, > Managing Off-Heap Memory, and Locking Memory as child links alongside the new > one. The rest become in-page TOC anchor links in Managing Heap Memory. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9435) Implement ZREMRANGEBYRANK Command
[ https://issues.apache.org/jira/browse/GEODE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9435: -- Labels: pull-request-available redis (was: redis) > Implement ZREMRANGEBYRANK Command > - > > Key: GEODE-9435 > URL: https://issues.apache.org/jira/browse/GEODE-9435 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, redis > > Implement the [ZREMRANGEBYRANK|https://redis.io/commands/zremrangebyrank] > command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9542: - Component/s: redis > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: redis > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
[ https://issues.apache.org/jira/browse/GEODE-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9544: - Component/s: redis > Update Certificate Used by Redis Server when Keystore Changes > - > > Key: GEODE-9544 > URL: https://issues.apache.org/jira/browse/GEODE-9544 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: redis > > When the TLS/SSL Certificate changes in the Java keystore, we want to be able > to automatically update the certificate, used by the server for TLS/SSL, > without requiring a restart of the server. > Although some changes will be necessary, we should be able to reuse much of > the work already implemented by the as part of GEODE-9017 and translate to > the appropriate Netty semantics. > > _Acceptance Criteria_ > A change in the TLS/SSL Certificate, in the keystore, is detected and > automatically applied to the server without requiring a server restart. > > Appropriate tests are written to ensure that this feature works and is not > regressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
[ https://issues.apache.org/jira/browse/GEODE-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9544: - Labels: redis (was: ) > Update Certificate Used by Redis Server when Keystore Changes > - > > Key: GEODE-9544 > URL: https://issues.apache.org/jira/browse/GEODE-9544 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > Labels: redis > > When the TLS/SSL Certificate changes in the Java keystore, we want to be able > to automatically update the certificate, used by the server for TLS/SSL, > without requiring a restart of the server. > Although some changes will be necessary, we should be able to reuse much of > the work already implemented by the as part of GEODE-9017 and translate to > the appropriate Netty semantics. > > _Acceptance Criteria_ > A change in the TLS/SSL Certificate, in the keystore, is detected and > automatically applied to the server without requiring a server restart. > > Appropriate tests are written to ensure that this feature works and is not > regressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9542: - Labels: redis (was: ) > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > Labels: redis > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9553) Review and eliminate all remaining usage of sprintf, snprintf, etc
Blake Bender created GEODE-9553:
---
Summary: Review and eliminate all remaining usage of sprintf,
snprintf, etc
Key: GEODE-9553
URL: https://issues.apache.org/jira/browse/GEODE-9553
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Blake Bender
>From time to time, we will pick up a new version of a compiler on one or
>another platform we build on, and get new complaints about potential buffer
>overflows or other assorted badness around persistent use of sprintf. See the
>following pull request, e.g.: https://github.com/apache/geode-native/pull/861
Fixing these when they come up is good as far as it goes, but we're really just
applying band-aids to the problem. *All* use of sprintf is bad, snprintf only
slightly less so. Someone needs to just go through the code and rewrite all
instances in modern C++ using std::string, std::stringstream, etc.
At a glance, here is the list of remaining files containing calls to sprintf:
{code}
c:\Users\bblake\src\geode-native>findstr /sm sprintf *.cpp
cppcache\integration\test\ThinClientConflation.cpp
cppcache\integration-test\fw_dunit.cpp
cppcache\integration-test\testCacheless.cpp
cppcache\integration-test\testOverflowPutGetSqLite.cpp
cppcache\integration-test\testRegionMap.cpp
cppcache\integration-test\testSerialization.cpp
cppcache\integration-test\testThinClientBigValue.cpp
cppcache\integration-test\testThinClientCacheablesLimits.cpp
cppcache\integration-test\testThinClientCacheableStringArray.cpp
cppcache\integration-test\testThinClientConflation.cpp
cppcache\integration-test\testThinClientCq.cpp
cppcache\integration-test\testThinClientCqDurable.cpp
cppcache\integration-test\testThinClientCqFailover.cpp
cppcache\integration-test\testThinClientCqHAFailover.cpp
cppcache\integration-test\testThinClientCqIR.cpp
cppcache\integration-test\testThinClientDeltaWithNotification.cpp
cppcache\integration-test\testThinClientGetInterests.cpp
cppcache\integration-test\testThinClientHADistOps.cpp
cppcache\integration-test\testThinClientHAEventIDMap.cpp
cppcache\integration-test\testThinClientHAFailover.cpp
cppcache\integration-test\testThinClientHAFailoverRegex.cpp
cppcache\integration-test\testThinClientHAMixedRedundancy.cpp
cppcache\integration-test\testThinClientHAPeriodicAck.cpp
cppcache\integration-test\testThinClientHeapLRU.cpp
cppcache\integration-test\testThinClientInterest1_Bug1001.cpp
cppcache\integration-test\testThinClientInterestNotify.cpp
cppcache\integration-test\testThinClientIntResPolKeysInv.cpp
cppcache\integration-test\testThinClientListenerCallbackArgTest.cpp
cppcache\integration-test\testThinClientLRUExpiration.cpp
cppcache\integration-test\testThinClientMultiDS.cpp
cppcache\integration-test\testThinClientNotificationWithDeltaWithoutcache.cpp
cppcache\integration-test\testThinClientPdxDeltaWithNotification.cpp
cppcache\integration-test\testThinClientPdxInstance.cpp
cppcache\integration-test\testThinClientPoolAttrTest.cpp
cppcache\integration-test\testThinClientPoolExecuteFunctionThrowsException.cpp
cppcache\integration-test\testThinClientPoolExecuteHAFunction.cpp
cppcache\integration-test\testThinClientPoolExecuteHAFunctionPrSHOP.cpp
cppcache\integration-test\testThinClientPoolRedundancy.cpp
cppcache\integration-test\testThinClientPRPutAllFailover.cpp
cppcache\integration-test\testThinClientRemoteQueryRS.cpp
cppcache\integration-test\testThinClientRemoteQuerySS.cpp
cppcache\integration-test\testThinClientRemoteRegionQuery.cpp
cppcache\integration-test\testThinClientRemoveOps.cpp
cppcache\integration-test\testThinClientSecurityPostAuthorization.cpp
cppcache\integration-test\testXmlCacheCreationWithPools.cpp
cppcache\integration-test\testXmlCacheInitialization.cpp
tests\cpp\security\PkcsCredentialGenerator.cpp
tests\cpp\security\XmlAuthzCredentialGenerator.cpp
tests\cpp\testobject\BatchObject.cpp
tests\cpp\testobject\DeltaPSTObject.cpp
tests\cpp\testobject\DeltaTestImpl.cpp
tests\cpp\testobject\EqStruct.cpp
tests\cpp\testobject\FastAssetAccount.cpp
tests\cpp\testobject\InvalidPdxUsage.cpp
tests\cpp\testobject\NestedPdxObject.cpp
tests\cpp\testobject\PdxClassV1.cpp
tests\cpp\testobject\PdxClassV2.cpp
tests\cpp\testobject\PdxType.cpp
tests\cpp\testobject\Portfolio.cpp
tests\cpp\testobject\PortfolioPdx.cpp
tests\cpp\testobject\Position.cpp
tests\cpp\testobject\PositionPdx.cpp
tests\cpp\testobject\PSTObject.cpp
tests\cpp\testobject\VariousPdxTypes.cpp
{code}
and snprintf:
{code}
c:\Users\bblake\src\geode-native>findstr /sm snprintf *.cpp
cppcache\src\CacheXmlParser.cpp
cppcache\src\CqEventImpl.cpp
cppcache\src\Log.cpp
cppcache\src\PdxFieldType.cpp
cppcache\src\PdxInstanceImpl.cpp
cppcache\src\RegionFactory.cpp
cppcache\src\RemoteQuery.cpp
cppcache\src\statistics\AtomicStatisticsImpl.cpp
cppcache\src\statistics\OsStatisticsImpl.cpp
cppcache\src\TcrMessage.cpp
cppcache\src\ThinClientRegion.cpp
