[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488913#comment-17488913 ] ASF GitHub Bot commented on GEODE-10016: mmartell merged pull request #918: URL: https://github.com/apache/geode-native/pull/918 -- 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 > Use Thread Name In Log Messages > --- > > Key: GEODE-10016 > URL: https://issues.apache.org/jira/browse/GEODE-10016 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > > The native client logging system currently prints the threadId in all log > messages. Since all internally created native client threads are named, we > should print the threadName instead of threadId. This will be extremely > helpful to understanding the flow of messages since there are many background > threads in the native client. > Note: Lots of log messages are running on an application thread which was not > created internally by the native client. Messages running on these threads > should continue to print the threadId. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10016) Use Thread Name In Log Messages
[ https://issues.apache.org/jira/browse/GEODE-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488914#comment-17488914 ] ASF subversion and git services commented on GEODE-10016: - Commit f60277dee9a33502a8fe832f5db54a8f9543eb32 in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=f60277d ] GEODE-10016: Add map of threadId to threadName (#918) * Save threadName to thread_local storage * Per review, get/setThreadName doesn't need tid * Add threadName in parens after tid * Update gnmsg for threadName * Move accessors to Log class * Inline threadNames instead of constants * Remove getThreadName() > Use Thread Name In Log Messages > --- > > Key: GEODE-10016 > URL: https://issues.apache.org/jira/browse/GEODE-10016 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > > The native client logging system currently prints the threadId in all log > messages. Since all internally created native client threads are named, we > should print the threadName instead of threadId. This will be extremely > helpful to understanding the flow of messages since there are many background > threads in the native client. > Note: Lots of log messages are running on an application thread which was not > created internally by the native client. Messages running on these threads > should continue to print the threadId. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10011) SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates is flaky
[
https://issues.apache.org/jira/browse/GEODE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10011:
--
Labels: flaky pull-request-available (was: pull-request-available)
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates
> is flaky
> -
>
> Key: GEODE-10011
> URL: https://issues.apache.org/jira/browse/GEODE-10011
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> {noformat}
> SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest >
> scanWithNoModificationsDoesNotReturnDuplicates FAILED
> java.lang.AssertionError: Property named
> 'scanWithNoModificationsDoesNotReturnDuplicates' failed (
> Expected size: 2 but was: 4 in:
> [176, 55, 176, 55]):
> With arguments: [[176, 55]]
> Original failure message:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> First arguments found to also provoke a failure: [[55, 202]]
> Seeds for reproduction: [5487908098719980972]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85)
> Caused by:
> java.lang.AssertionError:
> Expected size: 2 but was: 4 in:
> [55, 202, 55, 202]
> at
> org.apache.geode.redis.internal.data.collections.SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.scanWithNoModificationsDoesNotReturnDuplicates(SizeableBytes2ObjectOpenCustomHashMapWithCursorQuickCheckTest.java:85){noformat}
> This failure is due to the test assuming that more than one scan is necessary
> to scan the entire map, but for small map sizes (the map in the failure above
> only has 2 keys) it's possible that the first scan will return all elements
> and a cursor value of 0, meaning that the second scan will also return all
> elements, leading to duplicate elements in the result.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9995:
-
Labels: flaky pull-request-available (was: pull-request-available)
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9993) Redis SMOVE command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9993: - Labels: blocks-1.15.0 pull-request-available unreleased (was: blocks-1.15.0 pull-request-available) > Redis SMOVE command should be atomic > > > Key: GEODE-9993 > URL: https://issues.apache.org/jira/browse/GEODE-9993 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0, 1.16.0 > > > The [documentation for the SMOVE command|https://redis.io/commands/SMOVE] > states that it is atomic. The current implementation in the geode-for-redis > module is not, which could result in partially-applied moves if servers crash > during a move. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the SMoveExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9994) Redis RENAME command should be atomic
[ https://issues.apache.org/jira/browse/GEODE-9994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9994: - Labels: blocks-1.15.0 pull-request-available unreleased (was: blocks-1.15.0 pull-request-available) > Redis RENAME command should be atomic > - > > Key: GEODE-9994 > URL: https://issues.apache.org/jira/browse/GEODE-9994 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Donal Evans >Assignee: Eric Zoerner >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0, 1.16.0 > > > The current implementation of RENAME in the geode-for-redis module is not > atomic, which could result in partially-applied renames if servers crash > during a rename. > The implementation should be changed to use the > 'lockedExecuteInTransaction()' method in the AbstractRenameExecutor class. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9971) Fix ping distributed test case after switching from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9971: - Labels: pull-request-available testing (was: pull-request-available) > Fix ping distributed test case after switching from docker-compose to > testcontainers > > > Key: GEODE-9971 > URL: https://issues.apache.org/jira/browse/GEODE-9971 > Project: Geode > Issue Type: Bug >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > Due to the changes done by GEODE-9156 to switch from docker-compose to > testcontainers test case > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers > from > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest was not working > properly even though it was failing. > The test must be enhanced to check that entries are wan replicated to the > other site (for example by checking that entries added locally do not leave > events in the gateway sender queues). > After that, the code of the test must be fixed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9965) geode release should not delete Kafka connector release
[ https://issues.apache.org/jira/browse/GEODE-9965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9965: - Issue Type: Task (was: Bug) > geode release should not delete Kafka connector release > --- > > Key: GEODE-9965 > URL: https://issues.apache.org/jira/browse/GEODE-9965 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > logic intended to retain 3 most-recent Geode minors inadvertently deleted > kafka-connector-1.1.0, which is on a separate release track but shares the > same release location in ASF -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9944) NPE could occur if HARegion is being created again but not fully initialized
[
https://issues.apache.org/jira/browse/GEODE-9944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9944:
-
Labels: GeodeOperationAPI pull-request-available unreleased (was:
GeodeOperationAPI pull-request-available)
> NPE could occur if HARegion is being created again but not fully initialized
> -
>
> Key: GEODE-9944
> URL: https://issues.apache.org/jira/browse/GEODE-9944
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> The stack trace for the NPE is:
> {noformat}
> fatal 2022/01/08 12:45:33.175 PST bridgegemfire7_host1_25026 Processor 7> tid=0x148] Uncaught exception processing
> QueueSynchronizationProcessor$QueueSynchronizationMessage@340d586b
> processorId=4029
> sender=rs-FullRegression15142100a3i3large-hydra-client-18(bridgegemfire6_host1_25009:25009):41006
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.getDispatchedEvents(QueueSynchronizationProcessor.java:160)
> at
> org.apache.geode.internal.cache.ha.QueueSynchronizationProcessor$QueueSynchronizationMessage.process(QueueSynchronizationProcessor.java:127)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doProcessingThread(ClusterOperationExecutors.java:391)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This could occur when a client is not able to re-auth in time, and the server
> removes the HARegionQueue to the client. When the client is able to re-auth
> later, the new HARegionQueue is created again. There is a race that when the
> server process the above message, the HARegionQueue is not fully initialized
> and cause this NPE.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9936) Throw error for commands with multiple keys that contain the wrong type key
[ https://issues.apache.org/jira/browse/GEODE-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9936: - Labels: pull-request-available unreleased (was: pull-request-available) > Throw error for commands with multiple keys that contain the wrong type key > --- > > Key: GEODE-9936 > URL: https://issues.apache.org/jira/browse/GEODE-9936 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Kristen >Assignee: Kristen >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > For commands that take in multiple keys as arguments, it does not throw an > error if the arguments consist of a valid key followed by a different type > key. > Fix it so a wrong type error is thrown and add two test. One test should > takes in valid key followed by a different type key. Then the other test > should switch the ordering of the keys. > The following commands need to be checked: ZUNIONSTORE, ZINTERSTORE, SMOVE, > SDIFF, and SDIFFSTORE -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9930) org.apache.geode.management.api.ClusterManagementOperation not marked @Experimental
[
https://issues.apache.org/jira/browse/GEODE-9930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9930:
-
Issue Type: Task (was: Bug)
> org.apache.geode.management.api.ClusterManagementOperation not marked
> @Experimental
> ---
>
> Key: GEODE-9930
> URL: https://issues.apache.org/jira/browse/GEODE-9930
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {{org.apache.geode.management.api.ClusterManagementOperation}} is
> experimental and should be annotated {{@Experimental}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16
[ https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9901: - Labels: testing (was: ) > Failing upgrade-test after Log4j 2.15 bump to 2.16 > -- > > Key: GEODE-9901 > URL: https://issues.apache.org/jira/browse/GEODE-9901 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.6 >Reporter: Steve Sienkowski >Priority: Major > Labels: testing > Fix For: 1.12.8, 1.13.7, 1.14.3, 1.15.0 > > > A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 > pipeline. > These issues are characterized by an error message of > `java.rmi.ConnectException: Connection refused to host:` > First failure here: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14] > Git commit introducing upgrade of log4j 2.15 to 2.16: > [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3] > Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898 > > > > Example error message: > > Task :geode-gfsh:upgradeTest > org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > > whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host > c9ef3b85f95a with 4 VMs with version 1.12.0 > Caused by: > java.rmi.ConnectException: Connection refused to host: 172.17.0.37; > nested exception is: > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9907) Geode-for-redis example failed with JedisNoReachableClusterNodeException: No reachable node in cluster
[
https://issues.apache.org/jira/browse/GEODE-9907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9907:
-
Labels: backport blocks-1.15.0 pull-request-available unreleased (was:
backport blocks-1.15.0 pull-request-available)
> Geode-for-redis example failed with JedisNoReachableClusterNodeException: No
> reachable node in cluster
> --
>
> Key: GEODE-9907
> URL: https://issues.apache.org/jira/browse/GEODE-9907
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: backport, blocks-1.15.0, pull-request-available,
> unreleased
> Fix For: 1.15.0, 1.16.0
>
>
>
> {code:java}
> > Task :geodeForRedis:run FAILED
> Exception in thread "main"
> redis.clients.jedis.exceptions.JedisNoReachableClusterNodeException: No
> reachable node in cluster
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnection(JedisSlotBasedConnectionHandler.java:117)
> at
> redis.clients.jedis.JedisSlotBasedConnectionHandler.getConnectionFromSlot(JedisSlotBasedConnectionHandler.java:139)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:118)
> at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.zadd(JedisCluster.java:1106)
> at
> org.apache.geode_examples.geodeForRedis.Example.populateSortedSet(Example.java:53)
> at org.apache.geode_examples.geodeForRedis.Example.main(Example.java:30)
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geodeForRedis:run'.
> > Process 'command '/usr/lib/jvm/bellsoft-java8-amd64/bin/java'' finished
> >with non-zero exit value 1
> {code}
>
> This might be related to [https://github.com/apache/geode-examples/pull/110]
> due to the location of the failure of the test
> org.apache.geode_examples.geodeForRedis.Example.main.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488984#comment-17488984 ] ASF subversion and git services commented on GEODE-9892: Commit 026e0fcbd3600a40ed384dfd0c06efeee5fcee3a in geode's branch refs/heads/GEODE-9892-Create-Infrastructure-for-Redis-Lists from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=026e0fc ] GEODE-9892: Add initial support for RedisLists - implements LPUSH, LPOP, LLEN > Create Infrastructure for Redis Lists > - > > Key: GEODE-9892 > URL: https://issues.apache.org/jira/browse/GEODE-9892 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > > Create the infrastructure for supporting Redis Lists including: > * Use of the appropriate underlying Java collection > * Implementing the [LPUSH|https://redis.io/commands/lpush] Command > * Implementing the [LRANGE|https://redis.io/commands/lrange] command > +Acceptance Critera+ > The LPUSH and LRANGE commands have been implemented with appropriate unit > testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is
[ https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9900: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > Make sure all commands are sending back AuthenticationExpiredException as is > > > Key: GEODE-9900 > URL: https://issues.apache.org/jira/browse/GEODE-9900 > Project: Geode > Issue Type: Bug > Components: client/server, security >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > As we have discovered in GEODE-9820, some commands (especially CQ commands) > are not sending back `AuthenticationExpiredException` to the client with > MessageType.EXCEPTION, hence causing the client not wrapping it in the > correct form (See `AbstractOp around L300), We need to: > 1. go over all the commands and find out what commands are NOT handling the > `AuthenticationExpiredExcpetion` correctly. > 2. fix these commands, catch `AuthenticationExpiredException` specifically > and do a `writeException` (leave all other exception handling intact) > 3. write tests to make sure we are sending the exception to the client. > #1 would help us determine how many commands are in need of this fix and size > this story correctly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9899) Fix concurrency issue in RedisSet during GII
[
https://issues.apache.org/jira/browse/GEODE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9899:
-
Labels: pull-request-available release-blocker unreleased (was:
pull-request-available release-blocker)
> Fix concurrency issue in RedisSet during GII
>
>
> Key: GEODE-9899
> URL: https://issues.apache.org/jira/browse/GEODE-9899
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, release-blocker, unreleased
> Fix For: 1.15.0
>
>
> For the most part, access to Radish structures is performed through redis
> commands and thus concurrent access is protected through the
> {{{}StripedCoordinator{}}}. However access outside this protection can occur
> directly through Geode internal flows. In particular, a GII process will
> access the data structures via the {{toData}} and {{fromData}} calls.
> Exceptions can occur if the structure is being modified and, at the same time
> being read. For Example:
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> at
> org.apache.geode.redis.internal.data.RedisSetTest.testConcurrency(RedisSetTest.java:350)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:30)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NullPointerException
> at
> it.unimi.dsi.fastutil.objects.ObjectOpenCustomHashSet$SetIterator.next(ObjectOpenCustomHashSet.java:422)
> at org.apache.geode.redis.internal.data.RedisSet.toData(RedisSet.java:211)
> at
> org.apache.geode.redis.internal.data.RedisSetTest.iterateOverSet(RedisSetTest.java:368)
> at
> org.apache.geode.redis.internal.data.RedisSetTest.lambda$testConcurrency$0(RedisSetTest.java:346)
> at
> org.apache.geode.test.junit.rules.ExecutorServiceRule.lambda$submit$2(ExecutorServiceRule.java:263)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker
[jira] [Updated] (GEODE-9885) StringsDUnitTest.givenBucketsMoveDuringAppend_thenDataIsNotLost fails with duplicated append
[
https://issues.apache.org/jira/browse/GEODE-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9885:
-
Labels: pull-request-available testing (was: pull-request-available test)
> StringsDUnitTest.givenBucketsMoveDuringAppend_thenDataIsNotLost fails with
> duplicated append
>
>
> Key: GEODE-9885
> URL: https://issues.apache.org/jira/browse/GEODE-9885
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0, 1.16.0
>
>
> The test appends a lot of strings to a key. It wound up adding (at least one)
> extra string to the stored string:
> {\{java.util.concurrent.ExecutionException: java.lang.AssertionError:
> unexpected -{append0}-key-3-27680 at index 27681 iterationCount=61995 in
> string}}
> The string "\{append0}-key-3-27680" appeared twice in sequence.
> Additional to this failure, the test should be modified to produce a more
> useful failure message. The current assertion prints the entire String upon
> failure, which can contain upwards of 50,000 repeats of the
> "\{append0}-key-3*" String, making the output large and unreadable. Consider
> using an assertion with {{.withFailureMessage()}} to produce a more useful
> error message rather than the currently used {{Assert.fail().}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9885) StringsDUnitTest.givenBucketsMoveDuringAppend_thenDataIsNotLost fails with duplicated append
[
https://issues.apache.org/jira/browse/GEODE-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9885:
-
Labels: pull-request-available test (was: pull-request-available)
> StringsDUnitTest.givenBucketsMoveDuringAppend_thenDataIsNotLost fails with
> duplicated append
>
>
> Key: GEODE-9885
> URL: https://issues.apache.org/jira/browse/GEODE-9885
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, test
> Fix For: 1.15.0, 1.16.0
>
>
> The test appends a lot of strings to a key. It wound up adding (at least one)
> extra string to the stored string:
> {\{java.util.concurrent.ExecutionException: java.lang.AssertionError:
> unexpected -{append0}-key-3-27680 at index 27681 iterationCount=61995 in
> string}}
> The string "\{append0}-key-3-27680" appeared twice in sequence.
> Additional to this failure, the test should be modified to produce a more
> useful failure message. The current assertion prints the entire String upon
> failure, which can contain upwards of 50,000 repeats of the
> "\{append0}-key-3*" String, making the output large and unreadable. Consider
> using an assertion with {{.withFailureMessage()}} to produce a more useful
> error message rather than the currently used {{Assert.fail().}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9872) DistTXPersistentDebugDUnitTest tests fail because "cluster configuration service not available"
[
https://issues.apache.org/jira/browse/GEODE-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9872:
-
Labels: GeodeOperationAPI pull-request-available testing (was:
GeodeOperationAPI pull-request-available)
> DistTXPersistentDebugDUnitTest tests fail because "cluster configuration
> service not available"
> ---
>
> Key: GEODE-9872
> URL: https://issues.apache.org/jira/browse/GEODE-9872
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, testing
> Fix For: 1.15.0
>
>
> I suspect this failure is due to something in the test framework, or perhaps
> one or more tests failing to manage ports correctly, allowing two or more
> tests to interfere with one another.
> In this distributed test:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/388]
> we see two failures. Here's the first full stack trace:
>
>
> {code:java}
> [error 2021/12/04 20:40:53.796 UTC
> tid=33] org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$e
[jira] [Updated] (GEODE-9875) AuthenticationRequiredException: Failed to find the authenticated user.
[
https://issues.apache.org/jira/browse/GEODE-9875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9875:
-
Labels: GeodeOperationAPI pull-request-available unreleased (was:
GeodeOperationAPI pull-request-available)
> AuthenticationRequiredException: Failed to find the authenticated user.
> ---
>
> Key: GEODE-9875
> URL: https://issues.apache.org/jira/browse/GEODE-9875
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Client connects to a server:
> One thread is doing puts using the connection with a valid uniqueId
> The ClientCacheUpdater thread failed to initialize, gets an IOException while
> trying to connect to the server:
> {quote}
> [warn 2021/12/06 17:41:16.345 PST edgegemfire1_host1_9691
> tid=0x37] Cache Client Updater Thread on
> rs-RunItNow-HQ1613a0i3large-hydra-client-30(bridgegemfire1_host1_13308:13308):41001
> port 23326 (rs-RunItNow-HQ1613a0i3large-hydra-client-30:23326): Caught
> following exception while attempting to create a server-to-client
> communication socket and will exit: java.net.SocketTimeoutException: Read
> timed out
> {quote}
> Then the ClientCacheUpdator resets the connections userId back to -1.
> The put thread uses this -1 as the uniqueId and then gets the exception back.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9877) GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed
[
https://issues.apache.org/jira/browse/GEODE-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9877:
-
Labels: pull-request-available testing (was: pull-request-available)
> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed
> --
>
> Key: GEODE-9877
> URL: https://issues.apache.org/jira/browse/GEODE-9877
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.14.1, 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/43]
> failed with
> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse
> {noformat}
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.Socket.bind(Socket.java:662)
> at
> org.apache.geode.redis.GeodeRedisServerStartupDUnitTest.startupFailsGivenPortAlreadyInUse(GeodeRedisServerStartupDUnitTest.java:115)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher
[jira] [Updated] (GEODE-9870) JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
[
https://issues.apache.org/jira/browse/GEODE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9870:
-
Labels: pull-request-available unreleased (was: pull-request-available
unable)
> JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
> --
>
> Key: GEODE-9870
> URL: https://issues.apache.org/jira/browse/GEODE-9870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> CI failure here
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315]:
>
> {code:java}
> AuthWhileServersRestartDUnitTest > testReconnectionWithAuthAndServerRestarts
> FAILED
> redis.clients.jedis.exceptions.JedisMovedDataException: MOVED 12539
> 127.0.0.1:26259
> at redis.clients.jedis.Protocol.processError(Protocol.java:119)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:826)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:147)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:131)
> at
> org.apache.geode.redis.internal.executor.auth.AuthWhileServersRestartDUnitTest.after(AuthWhileServersRestartDUnitTest.java:88){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9870) JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
[
https://issues.apache.org/jira/browse/GEODE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9870:
-
Labels: pull-request-available unable (was: pull-request-available)
> JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
> --
>
> Key: GEODE-9870
> URL: https://issues.apache.org/jira/browse/GEODE-9870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: pull-request-available, unable
> Fix For: 1.15.0
>
>
> CI failure here
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315]:
>
> {code:java}
> AuthWhileServersRestartDUnitTest > testReconnectionWithAuthAndServerRestarts
> FAILED
> redis.clients.jedis.exceptions.JedisMovedDataException: MOVED 12539
> 127.0.0.1:26259
> at redis.clients.jedis.Protocol.processError(Protocol.java:119)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:826)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:147)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:131)
> at
> org.apache.geode.redis.internal.executor.auth.AuthWhileServersRestartDUnitTest.after(AuthWhileServersRestartDUnitTest.java:88){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9864) HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails infrequently
[
https://issues.apache.org/jira/browse/GEODE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9864:
-
Labels: testing (was: )
> HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails
> infrequently
> --
>
> Key: GEODE-9864
> URL: https://issues.apache.org/jira/browse/GEODE-9864
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jens Deppe
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost fails
> infrequently with one key's value being null instead of the expected value.
> {code:java}
> java.util.concurrent.ExecutionException: org.opentest4j.AssertionFailedError:
> expected: "set-key-0-1794"
> but was: null
> at
> java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at
> java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908)
> at
> org.apache.geode.redis.internal.executor.hash.HashesAndCrashesDUnitTest.modifyDataWhileCrashingVMs(HashesAndCrashesDUnitTest.java:182)
> at
> org.apache.geode.redis.internal.executor.hash.HashesAndCrashesDUnitTest.givenServerCrashesDuringSET_thenDataIsNotLost(HashesAndCrashesDUnitTest.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestE
[jira] [Updated] (GEODE-9867) NPE When a connection is terminated after the client already sent in the operation
[ https://issues.apache.org/jira/browse/GEODE-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9867: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > NPE When a connection is terminated after the client already sent in the > operation > -- > > Key: GEODE-9867 > URL: https://issues.apache.org/jira/browse/GEODE-9867 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > The sequence of action is: > # the client sent in the operation to the server > # the message dispatcher to the client encountered some error and unregister > this client and terminates the connection > # the other thread continues to use the connection to process the command > and we get the NPE: > > java.lang.NullPointerException > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:907) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:867) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1055) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1326) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9862) build broken by grgit dependencies
[ https://issues.apache.org/jira/browse/GEODE-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9862: - Issue Type: Task (was: Bug) > build broken by grgit dependencies > -- > > Key: GEODE-9862 > URL: https://issues.apache.org/jira/browse/GEODE-9862 > Project: Geode > Issue Type: Task > Components: build, ci >Affects Versions: 1.14.0, 1.15.0 >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.14.1, 1.15.0 > > > CI build started failing, and many local builds once gradle caches were > updated. Logs > [here|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0696/test-results/build/1638221535/]. > > We need to pin `org.eclipse.jgit` to fix for now. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9856) SMoveNativeRedisAcceptanceTest is failing with cluster is down.
[
https://issues.apache.org/jira/browse/GEODE-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9856:
-
Labels: testing (was: )
> SMoveNativeRedisAcceptanceTest is failing with cluster is down.
> ---
>
> Key: GEODE-9856
> URL: https://issues.apache.org/jira/browse/GEODE-9856
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> {noformat}
> SMoveNativeRedisAcceptanceTest > testSMoveNegativeCases FAILED
> 12:05:00redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN
> The cluster is down
> 12:05:00at
> redis.clients.jedis.Protocol.processError(Protocol.java:125)
> 12:05:00at redis.clients.jedis.Protocol.process(Protocol.java:169)
> 12:05:00at redis.clients.jedis.Protocol.read(Protocol.java:223)
> 12:05:00at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> 12:05:00at
> redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> 12:05:00at redis.clients.jedis.Jedis.sadd(Jedis.java:1391)
> 12:05:00at
> redis.clients.jedis.JedisCluster$70.execute(JedisCluster.java:973)
> 12:05:00at
> redis.clients.jedis.JedisCluster$70.execute(JedisCluster.java:970)
> 12:05:00at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> 12:05:00at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> 12:05:00at
> redis.clients.jedis.JedisCluster.sadd(JedisCluster.java:975)
> 12:05:00at
> org.apache.geode.redis.internal.executor.set.AbstractSMoveIntegrationTest.testSMoveNegativeCases(AbstractSMoveIntegrationTest.java:112)
> 12:05:00at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 12:05:00at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 12:05:00at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 12:05:00at java.lang.reflect.Method.invoke(Method.java:498)
> 12:05:00at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 12:05:00at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 12:05:00at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 12:05:00at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 12:05:00at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 12:05:00at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 12:05:00at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 12:05:00at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 12:05:00at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 12:05:00at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 12:05:00at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 12:05:00at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 12:05:00at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> 12:05:00at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> 12:05:00at
> org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> 12:05:00at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> 12:05:00at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:118)
> 12:05:00at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 12:05:00at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 12:05:00at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 12:05:00at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 12:05:00at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 12:05:00at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> 12:05:00at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> 12:05:00at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> 12:05:00at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> 12:05:00at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> 12:05:00at java.util.Iterator.forEachRemaining(Iterator.ja
[jira] [Updated] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9824: - Labels: GeodeOperationAPI pull-request-available testing (was: GeodeOperationAPI pull-request-available) > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, testing > Fix For: 1.15.0 > > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[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 ] Anthony Baker updated GEODE-9554: - Labels: pull-request-available unreleased (was: pull-request-available) > 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 >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.12.5, 1.13.5, 1.14.1, 1.15.0 > > > 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.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9815: - Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available unreleased (was: GeodeOperationAPI blocks-1.15.0 pull-request-available) > Recovering persistent members can result in extra copies of a bucket or two > copies in the same redundancy zone > -- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, > pull-request-available, unreleased > Fix For: 1.15.0 > > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 > and B1 > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9811: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core, security >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9794) Radish PassiveExpirationManager can throw NPE
[
https://issues.apache.org/jira/browse/GEODE-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9794:
-
Labels: pull-request-available unreleased (was: pull-request-available
unable)
> Radish PassiveExpirationManager can throw NPE
> -
>
> Key: GEODE-9794
> URL: https://issues.apache.org/jira/browse/GEODE-9794
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> I noticed this log entry in a recent test:
>
> {noformat}
> [warn 2021/11/02 15:12:08.402 PDT redisServergemfire1_host1_9725
> tid=0x47] Passive expiration failed. Will
> try again in 1 second.
> java.lang.NullPointerException
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.doDataExpiration(PassiveExpirationManager.java:66)
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.lambda$new$0(PassiveExpirationManager.java:49)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9805) Debug logging of Radish AUTH command in ExecutionHandlerContext.executeCommand() reveals sensitive information
[ https://issues.apache.org/jira/browse/GEODE-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9805: - Labels: blocks-1.15.0 pull-request-available unreleased (was: blocks-1.15.0 pull-request-available) > Debug logging of Radish AUTH command in > ExecutionHandlerContext.executeCommand() reveals sensitive information > -- > > Key: GEODE-9805 > URL: https://issues.apache.org/jira/browse/GEODE-9805 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available, unreleased > Fix For: 1.15.0 > > > With debug logging enabled, the ExecutionHandlerContext.executeCommand() > method logs every command executed along with its arguments. In the case of > the AUTH command, this results in un-redacted userId and/or password being > logged, which represents a serious security issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9794) Radish PassiveExpirationManager can throw NPE
[
https://issues.apache.org/jira/browse/GEODE-9794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9794:
-
Labels: pull-request-available unable (was: pull-request-available)
> Radish PassiveExpirationManager can throw NPE
> -
>
> Key: GEODE-9794
> URL: https://issues.apache.org/jira/browse/GEODE-9794
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unable
> Fix For: 1.15.0
>
>
> I noticed this log entry in a recent test:
>
> {noformat}
> [warn 2021/11/02 15:12:08.402 PDT redisServergemfire1_host1_9725
> tid=0x47] Passive expiration failed. Will
> try again in 1 second.
> java.lang.NullPointerException
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.doDataExpiration(PassiveExpirationManager.java:66)
> at
> org.apache.geode.redis.internal.PassiveExpirationManager.lambda$new$0(PassiveExpirationManager.java:49)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9778:
-
Labels: pull-request-available testing unreleased (was:
pull-request-available unreleased)
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, testing, unreleased
> Fix For: 1.14.1, 1.15.0
>
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9792) Client in some cases would send in AuthenticationRequest multiple times even when they share the same connection
[ https://issues.apache.org/jira/browse/GEODE-9792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9792: - Labels: GeodeOperationAPI pull-request-available unreleased (was: GeodeOperationAPI pull-request-available) > Client in some cases would send in AuthenticationRequest multiple times even > when they share the same connection > > > Key: GEODE-9792 > URL: https://issues.apache.org/jira/browse/GEODE-9792 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, unreleased > Fix For: 1.15.0 > > > It's observed that AuthenticationRequest will come in multiple times in the > same connection by different threads. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9778:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.14.1, 1.15.0
>
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9767: - Issue Type: Improvement (was: Bug) > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9751) [CI-only] render.py needs to call yaml.safe_load instead of yaml.load
[ https://issues.apache.org/jira/browse/GEODE-9751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9751: - Issue Type: Task (was: Bug) > [CI-only] render.py needs to call yaml.safe_load instead of yaml.load > - > > Key: GEODE-9751 > URL: https://issues.apache.org/jira/browse/GEODE-9751 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.12.5, 1.13.5, 1.14.1, 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > after previously being deprecated, the latest version of pyyaml removes this > insecure call (see > https://stackoverflow.com/questions/69564817/typeerror-load-missing-1-required-positional-argument-loader-in-google-col). > render.py is used in several jobs in our meta pipeline to transform our > jinja2 templates into concourse yaml. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9745) geode-for-redis stats expose unbranded names
[ https://issues.apache.org/jira/browse/GEODE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9745: - Labels: pull-request-available unreleased (was: pull-request-available) > geode-for-redis stats expose unbranded names > > > Key: GEODE-9745 > URL: https://issues.apache.org/jira/browse/GEODE-9745 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The stats for geode-for-redis when seen in an external tool (like vsd) are > named "redisStats". They should instead be "geodeForRedisStats". Also the > type name is very non-standard and too wordy "statsForServergeodeForRedis". > It should just be "GeodeForRedisStats". > The description also has some old terminology "Statistics for a Geode server > compatible with Redis". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9736) publishes that find no pattern subscribers can cause server to run out of memory
[ https://issues.apache.org/jira/browse/GEODE-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9736: - Labels: unreleased (was: ) > publishes that find no pattern subscribers can cause server to run out of > memory > > > Key: GEODE-9736 > URL: https://issues.apache.org/jira/browse/GEODE-9736 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: unreleased > Fix For: 1.15.0 > > > Currently each time a publish is done the server will check existing pattern > subscribers to see if they want the publish. If it finds no subscribers it > remembers that and the publish channel. > Since you can just keep making up new publish channels that have no memory, > remembering these can cause the server to run out of memory. > If you hit this problem you will see an instance of > PatternSubscriptionManager with a large "patternSubscriptionCache" > ConcurrentHashMap. It will be full of entries whose value is an instance of > Collections$EmptyList -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9725) AvailablePort inherently incompatible with default membership port range
[
https://issues.apache.org/jira/browse/GEODE-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9725:
-
Labels: GeodeOperationAPI pull-request-available testing (was:
GeodeOperationAPI pull-request-available)
> AvailablePort inherently incompatible with default membership port range
>
>
> Key: GEODE-9725
> URL: https://issues.apache.org/jira/browse/GEODE-9725
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, testing
> Fix For: 1.15.0
>
>
> {{AvailablePortHelperIntegrationTest}} failed in CI:
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259]
> *Cause:* {{AvailablePort}} and {{AvailablePortHelper}} have methods to
> retrieve an "available" port from the membership port range. This feature is
> both unnecessary and inherently unreliable.
> *Inherently unreliable:* The default membership port range overlaps each OS's
> ephemeral port range. An ephemeral port deemed to be "available" by one of
> these methods can be put into use by another process even before the method
> returns. It is not safe to rely on such a port to remain available after it
> is checked.
> *Unnecessary:* Currently the only callers that request ports from the
> membership port range are two tests in {{DistributedSystemDUnitTest}}. In
> each case, the test uses the returned ports to +set+ the membership port
> range for a member. There is no need for the ports to come from any
> particular range.
> There are no other uses of this feature, either in the product or in tests.
> *Solution:* Remove this feature from {{AvailablePort}} and
> {{AvailablePortHelper}}.
> *Alternatives:*
> * {{DistributedSystemDUnitTest}} can get available ports from the available
> port range. This range is safe to use (assuming all other
> concurrently-running tests are well-behaved).
> * A caller that needs ports in a specific range can call
> {{AvailablePort.getRandomAvailablePortInRange(lower, upper, protocol)}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9734: - Labels: pull-request-available unreleased (was: pull-request-available) > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
[ https://issues.apache.org/jira/browse/GEODE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9721: - Labels: pull-request-available unreleased (was: pull-request-available) > the constant names for redis gemfire properties should contain GEODE_FOR_REDIS > -- > > Key: GEODE-9721 > URL: https://issues.apache.org/jira/browse/GEODE-9721 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The following constant names in ConfigurationProperties should all be > renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS > to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, > GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9727: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9709) Clean up GcCommandDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9709: - Labels: pull-request-available testing (was: pull-request-available) > Clean up GcCommandDUnitTest > --- > > Key: GEODE-9709 > URL: https://issues.apache.org/jira/browse/GEODE-9709 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9702) japicmp should fail when new methods are added to public interface
[ https://issues.apache.org/jira/browse/GEODE-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9702: - Issue Type: Task (was: Bug) > japicmp should fail when new methods are added to public interface > -- > > Key: GEODE-9702 > URL: https://issues.apache.org/jira/browse/GEODE-9702 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > At least twice in 1.15.0 (commits 7aa03824 and b377e3f8), new methods were > added to Geode's public API (such as > `GatewaySender.getRetriesToGetTransactionEventsFromQueue`). While adding > methods _is_ compatible with existing source and binary calls to this > interface, it breaks anything else that implements this interface. _Even if_ > a default implementation had been provided, there are still edge cases where > it could collide with existing implementation that may already have methods > with those names. These two examples have been fixed now by GEODE-9629 and > GEODE-9630; this ticket is to fix CI to prevent this in the future. > Our required PR check "*api-check-test-openjdk11*" should have prevented this > from happening... > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9707) artifacts not archived when a ci job fails due to OOM
[ https://issues.apache.org/jira/browse/GEODE-9707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9707: - Issue Type: Task (was: Bug) > artifacts not archived when a ci job fails due to OOM > - > > Key: GEODE-9707 > URL: https://issues.apache.org/jira/browse/GEODE-9707 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > example: https://concourse.apachegeode-ci.info/builds/86869 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9703) redis benchmarks fail to compile after rename
[ https://issues.apache.org/jira/browse/GEODE-9703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9703: - Issue Type: Task (was: Bug) > redis benchmarks fail to compile after rename > - > > Key: GEODE-9703 > URL: https://issues.apache.org/jira/browse/GEODE-9703 > Project: Geode > Issue Type: Task > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Looks like Redis Benchmarks are [failing to > compile|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/115] > the baseline after the rename, since the module name is now different in > HEAD than in the baseline. The easiest fix might be to update [the redis > baseline|https://github.com/apache/geode/blob/develop/ci/pipelines/shared/jinja.variables.yml#L41] > to some Geode SHA *after* the big rename (the current redis benchmark > baseline SHA is from Aug 18) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9701) ClusterStartupRule starts 4 VMs even if fewer VMs is specified
[
https://issues.apache.org/jira/browse/GEODE-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9701:
-
Labels: GeodeOperationAPI pull-request-available testing (was:
GeodeOperationAPI pull-request-available)
> ClusterStartupRule starts 4 VMs even if fewer VMs is specified
> --
>
> Key: GEODE-9701
> URL: https://issues.apache.org/jira/browse/GEODE-9701
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, testing
> Fix For: 1.15.0
>
>
> Bill reported that ClusterStartupRule seems to be creating 4 VMs no matter
> how few VMs he specifies in a new test for [PR
> #6930|https://github.com/apache/geode/pull/6930]. The concern is that by
> creating more VMs, we are causing unnecessary load on machines in the cloud.
> I wrote this simple test which confirms the problem:
> {noformat}
> import static org.apache.geode.test.dunit.VM.getVMCount;
> import static org.assertj.core.api.Assertions.assertThat;
> import org.junit.Rule;
> import org.junit.Test;
> import org.apache.geode.test.dunit.rules.ClusterStartupRule;
> public class ClusterStartupRuleVmCountDistributedTest {
> @Rule
> public ClusterStartupRule clusterStartupRule = new ClusterStartupRule(3);
> @Test
> public void limitsVMsTo3() {
> assertThat(getVMCount()).isEqualTo(3);
> }
> }
> {noformat}
> But if I replace {{ClusterStartupRule}} with {{DistributedRule}}, it passes
> so the problem is specific to {{ClusterStartupRule}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9693) Remove deprecated elements from ListIndexCommandDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9693: - Labels: pull-request-available testing (was: pull-request-available) > Remove deprecated elements from ListIndexCommandDistributedTestBase > --- > > Key: GEODE-9693 > URL: https://issues.apache.org/jira/browse/GEODE-9693 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9699) ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
[
https://issues.apache.org/jira/browse/GEODE-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9699:
-
Labels: pull-request-available release-blocker unreleased (was:
pull-request-available release-blocker)
> ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
>
>
> Key: GEODE-9699
> URL: https://issues.apache.org/jira/browse/GEODE-9699
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Eric Zoerner
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, release-blocker, unreleased
> Fix For: 1.15.0
>
>
> The following redis TCL test fails when running against Geode for Redis:
> {code}
> # Geode fails with: Expected '1' to be equal to '0'
> test "ZUNIONSTORE against non-existing key doesn't set destination -
> $encoding" {
> r del "{slot}zseta"
> assert_equal 0 [r zunionstore "{slot}dst_key" 1 "{slot}zseta"]
> assert_equal 0 [r exists "{slot}dst_key"]
> }
> {code}
> Enable this test as part of this fix.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9690) Restore Redis TCL integration test patch file
[ https://issues.apache.org/jira/browse/GEODE-9690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9690: - Labels: pull-request-available testing (was: pull-request-available) > Restore Redis TCL integration test patch file > - > > Key: GEODE-9690 > URL: https://issues.apache.org/jira/browse/GEODE-9690 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > GEODE-9567 accidentally removed the Redis TCL patch file. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9687) Remove deprecated elements from RegionMembershipMBeanDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9687: - Labels: pull-request-available testing (was: pull-request-available) > Remove deprecated elements from RegionMembershipMBeanDistributedTestBase > > > Key: GEODE-9687 > URL: https://issues.apache.org/jira/browse/GEODE-9687 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9665) RENAME or RENAMENX using keys on different servers causes multiple redirections
[ https://issues.apache.org/jira/browse/GEODE-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9665: - Labels: pull-request-available unreleased (was: pull-request-available) > RENAME or RENAMENX using keys on different servers causes multiple > redirections > --- > > Key: GEODE-9665 > URL: https://issues.apache.org/jira/browse/GEODE-9665 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > when running on a multi-server cluster, an attempt to rename with source and > target keys that are hosted on different servers causes multiple MOVED > redirects. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9645) MultiUserAuth: DataSerializerRecoveryListener is called without auth information. Promptly fails
[
https://issues.apache.org/jira/browse/GEODE-9645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9645:
-
Labels: GeodeOperationAPI pull-request-available unreleased (was:
GeodeOperationAPI pull-request-available)
> MultiUserAuth: DataSerializerRecoveryListener is called without auth
> information. Promptly fails
>
>
> Key: GEODE-9645
> URL: https://issues.apache.org/jira/browse/GEODE-9645
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> When multiuserSecureModeEnabled is enabled, a user may register a
> DataSerializer. When endpoint manager detects a new endpoint, it will attempt
> to register the data serializers with other machines. This is a problem was
> there is no authentication information in the background process to
> authenticate. Hence the error seen below.
>
> {noformat}
> [warn 2021/09/27 18:03:02.804 PDT tid=0x62]
> DataSerializerRecoveryTask - Error recovering dataSerializers:
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1540)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.RegisterDataSerializersOp.execute(RegisterDataSerializersOp.java:40)
>
> at
> org.apache.geode.cache.client.internal.DataSerializerRecoveryListener$RecoveryTask.run2(DataSerializerRecoveryListener.java:116)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1337)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9641) Benchmark instability in P2pPartitionedPutBytesBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9641:
-
Labels: pull-request-available testing (was: pull-request-available)
> Benchmark instability in P2pPartitionedPutBytesBenchmark
>
>
> Key: GEODE-9641
> URL: https://issues.apache.org/jira/browse/GEODE-9641
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> P2pPartitionedPutBytesBenchmark started failing in CI after the fix for
> GEODE-9204 was merged.
> {code:java}
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark
> average ops/second Baseline:179582.83 Test:170268.31
> Difference: -5.2%
>ops/second standard error Baseline: 849.15 Test: 649.44
> Difference: -23.5%
>ops/second standard deviation Baseline: 25346.86 Test: 19374.76
> Difference: -23.6%
> YS 99th percentile latency Baseline: 5010.00 Test: 5110.00
> Difference: +2.0%
> median latency Baseline: 2416639.00 Test: 2412543.00
> Difference: -0.2%
> 90th percentile latency Baseline: 4698111.00 Test: 4567039.00
> Difference: -2.8%
> 99th percentile latency Baseline: 38141951.00 Test: 81723391.00
> Difference: +114.3%
>99.9th percentile latency Baseline: 196214783.00 Test: 205389823.00
> Difference: +4.7%
> average latency Baseline: 4033453.68 Test: 4258029.39
> Difference: +5.6%
> latency standard deviation Baseline: 14549153.77 Test: 15673393.37
> Difference: +7.7%
> latency standard error Baseline: 1149.00 Test: 1271.79
> Difference: +10.7%
> average ops/second Baseline:533863.27 Test:505986.13
> Difference: -5.2%
> BENCHMARK FAILED:
> org.apache.geode.benchmark.tests.P2pPartitionedPutBytesBenchmark average
> latency is 5% worse than baseline.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9607) radish publish or subscribe operations could run the server out of memory
[ https://issues.apache.org/jira/browse/GEODE-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9607: - Labels: pull-request-available unreleased (was: pull-request-available) > radish publish or subscribe operations could run the server out of memory > - > > Key: GEODE-9607 > URL: https://issues.apache.org/jira/browse/GEODE-9607 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Each subscribe op stores some data in the server memory. If you keep doing > this the server will eventually run out of memory. Operations that store data > are supposed to honor the geode critical memory threshold and fail with a > LowMemory exception but subscribe does no check for critical but instead just > uses more memory. > Each publish op is added to an unbound queue that can take a while to process > (longer when more than one server is running). If enough publish ops are > received in a burst they can also cause the server to run out of memory. > Before adding the op to the queue geode's critical memory threshold should be > checked. > Since the server queues publish ops and needs to send them to remote servers > using a geode function, the implementation should be enhanced to do this with > a batch of publish ops instead of doing them one at a time. This will > improve the performance of publish which will allow it to free up memory > faster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9582) redis glob pattern should never throw PatternSyntaxException
[
https://issues.apache.org/jira/browse/GEODE-9582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9582:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> redis glob pattern should never throw PatternSyntaxException
>
>
> Key: GEODE-9582
> URL: https://issues.apache.org/jira/browse/GEODE-9582
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> The GlobPattern class converts a user's glob pattern into a pattern that is
> compiled by the jdk's Pattern.compile method. Some character sequences will
> cause the jdk to throw PatternSynaxException. For example giving it the bytes
> {{stringToBytes("\C")}} causes an exception.
> Native redis with this same pattern treats it like just "C".
> I think we need to look at every case in which the jdk compile throws
> PatternSynaxException and make sure GlobPattern will not submit a pattern to
> Pattern.compile that will cause it to throw.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9581:
-
Labels: pull-request-available testing (was: pull-request-available)
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9564) Radish ParameterRequirements package name does not follow naming conventions
[ https://issues.apache.org/jira/browse/GEODE-9564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9564: - Labels: pull-request-available unreleased (was: pull-request-available) > Radish ParameterRequirements package name does not follow naming conventions > > > Key: GEODE-9564 > URL: https://issues.apache.org/jira/browse/GEODE-9564 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Per [the style > guide|https://google.github.io/styleguide/javaguide.html#s5.2.1-package-names] > adopted by Geode, package names should be all lower-case. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9574) Changes to exception handling may be causing changes to connection state.
[
https://issues.apache.org/jira/browse/GEODE-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9574:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Changes to exception handling may be causing changes to connection state.
> -
>
> Key: GEODE-9574
> URL: https://issues.apache.org/jira/browse/GEODE-9574
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> {{OpExectorImpl}} has very specific exception cause checks that may have been
> affected by adding a cause to certain exceptions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9500) RedisData keeps DeltaInfo references too long
[ https://issues.apache.org/jira/browse/GEODE-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9500: - Labels: pull-request-available unreleased (was: pull-request-available) > RedisData keeps DeltaInfo references too long > - > > Key: GEODE-9500 > URL: https://issues.apache.org/jira/browse/GEODE-9500 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The current implementation of Delta for RedisData does not clear the > reference to the DeltaInfo until toDelta is called. This works fine in the > normal case but in the abnormal case it can case extra memory to be used by > the DeltaInfo instances being kept alive. > What can happen is that if the extra server goes down so that geode is > running with one server then some optimization are done by geode and it never > calls toDelta. So in that case the DeltaInfo instances will be kept stored on > the primary. > We actually have sizing tests that found this problem but those tests were > changes to clear the DeltaInfo reference in the test. > Instead we should have these tests not clear it and change geode to clear it > in AbstractRedisData.storeChanges after the put returns. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9493) redis data structure sizing is hard coded for compressed oops
[ https://issues.apache.org/jira/browse/GEODE-9493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9493: - Labels: pull-request-available unreleased (was: pull-request-available) > redis data structure sizing is hard coded for compressed oops > - > > Key: GEODE-9493 > URL: https://issues.apache.org/jira/browse/GEODE-9493 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The sizing of the redis data structures (string, hash, set, sorted set) has > some constants that were precomputed by tests. Because the tests are run with > smaller heaps that use compressed oops the size estimates end up being too > small for large heaps or if compressed oops are disabled. > Also a "strategy" object is currently part of the size and should not be > since it is a single canonical instance shared by all hash and set instances. > Also the way sizing is currently done does not take advantage of us knowing > the element type. By optimizing the code for "byte[]" for example we can > compute the size faster and use less memory by storing less "sizing" state in > our objects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9482) Radish commands do not match Redis error behaviour for integer arguments beginning "-0" and "+"
[
https://issues.apache.org/jira/browse/GEODE-9482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9482:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish commands do not match Redis error behaviour for integer arguments
> beginning "-0" and "+"
> ---
>
> Key: GEODE-9482
> URL: https://issues.apache.org/jira/browse/GEODE-9482
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> When using native Redis, commands that take integer arguments return {{"ERR
> value is not an integer or out of range"}} if the argument begins with "-0"
> or "+". The current implementation of these commands in Geode does not behave
> the same way.
> The {{Coder.bytesToLong()}} method should be modified to check for the first
> two characters being "-0" or "+" and throw a {{NumberFormatException}} if
> that is the case. Alternately, if there are places where we want to preserve
> the existing behaviour of {{Coder.bytesToLong()}}, an additional
> {{bytesToLongStrict()}} method could be added to the {{Coder}} class with
> this additional check.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9481) Upgrade OldClientSupportDUnitTest to not use deprecated methods
[ https://issues.apache.org/jira/browse/GEODE-9481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9481: - Labels: pull-request-available testing (was: pull-request-available) > Upgrade OldClientSupportDUnitTest to not use deprecated methods > --- > > Key: GEODE-9481 > URL: https://issues.apache.org/jira/browse/GEODE-9481 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9429) Radish HSCAN implementation cannot handle values for COUNT greater than Integer.MAX_VALUE / 2
[
https://issues.apache.org/jira/browse/GEODE-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9429:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish HSCAN implementation cannot handle values for COUNT greater than
> Integer.MAX_VALUE / 2
> -
>
> Key: GEODE-9429
> URL: https://issues.apache.org/jira/browse/GEODE-9429
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> The below code is the current implementation of HSCAN in {{RedisHash}}. When
> the value of {{count}} passed to this method is greater than
> {{Integer.MAX_VALUE / 2}} the condition of the while loop suffers from
> integer overflow and the loop does not execute correctly.
> {code:java}
> public ImmutablePair> hscan(Pattern matchPattern, int
> count, int cursor) {
> ArrayList resultList = new ArrayList<>(count + 2);
> do {
> cursor = hash.scan(cursor, 1,
> (list, key, value) -> addIfMatching(matchPattern, list, key,
> value), resultList);
> } while (cursor != 0 && resultList.size() < (count * 2));
> return new ImmutablePair<>(cursor, resultList);
> {code}
> This could be fixed by changing the type of {{resultList}} to
> {{List>}} and modifying the {{addIfMatching()}}
> method to populate the list with {{ImmutablePair}}s of keys and values rather
> than a single continuous list of interleaved keys and values.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9411:
-
Labels: pull-request-available unable (was: pull-request-available)
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unable
> Fix For: 1.15.0
>
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9424) Radish command arguments must support Long values
[
https://issues.apache.org/jira/browse/GEODE-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9424:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Radish command arguments must support Long values
> -
>
> Key: GEODE-9424
> URL: https://issues.apache.org/jira/browse/GEODE-9424
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> To match the behaviour seen when using native Redis, all command arguments
> that take integer values (that is, as opposed to float or string) must allow
> values in the range of {{Long.MIN_VALUE}} -> {{Long.MAX_VALUE}}.
> Currently, passing a value smaller than {{Integer.MIN_VALUE}} or larger than
> {{Integer.MAX_VALUE}} to these commands results in an error being returned,
> which is not the case for native Redis.
> Currently affected commands are:
> SCAN
> SSCAN
> HSCAN
> SPOP
> SRANDMEMBER
> BITPOS
> GETBIT
> SETBIT
> SETRANGE
> It should be enough to simply parse the argument as a Long and then narrow it
> to an int in most cases, as internally the maximum value that the argument
> can possibly take is {{Integer.MAX_VALUE}}. For example, [the maximum number
> of elements in a Redis set is 2^32 -
> 1|https://redis.io/topics/data-types#sets], so the largest meaningful value
> for the SSCAN CURSOR argument internally is {{Integer.MAX_VALUE}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9427) Radish HSCAN implementation does not accept values for CURSOR argument that match Redis
[
https://issues.apache.org/jira/browse/GEODE-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9427:
-
Labels: unreleased (was: )
> Radish HSCAN implementation does not accept values for CURSOR argument that
> match Redis
> ---
>
> Key: GEODE-9427
> URL: https://issues.apache.org/jira/browse/GEODE-9427
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: unreleased
> Fix For: 1.15.0
>
>
> The HSCAN command takes an argument, CURSOR, which in native Redis can be any
> value between -18446744073709551615 and 18446744073709551615 (the maximum
> value of an unsigned long). The Radish implementation of HSCAN only accepts
> values in the range {{Integer.MIN_VALUE}} -> {{Integer.MAX_VALUE}} and
> returns an error if values outside this range are used.
> The Radish HSCAN implementation should be modified to accept the same range
> of values as Redis. Examples of this can be found in the implementations of
> the currently unsupported SCAN and SSCAN commands.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9417) ZRANGE Behavior After Deletion of Key Inconsistent With Redis
[ https://issues.apache.org/jira/browse/GEODE-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9417: - Labels: blocks-1.15.0 redis unreleased (was: blocks-1.15.0 redis) > ZRANGE Behavior After Deletion of Key Inconsistent With Redis > - > > Key: GEODE-9417 > URL: https://issues.apache.org/jira/browse/GEODE-9417 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, redis, unreleased > Fix For: 1.15.0 > > > After deleting a SortedSet the behavior for ZRANGE differs from native Redis. > > +Reproduction Steps:+ > Add some data to a SortedSet: > * ZADD leaderboard 1 "one" > * ZADD leaderboard 2 "two" > Delete the SortedSet with the key "leaderboard": > * DEL leaderboard > Now perform a ZRANGE command on the deleted key > ZRANGE leaderboard 0 10 > > Native Redis returns "(empty array)" where as we return " > "(error) ERR The server had an internal error please try again". > > The same behavior occurs even if the SortedSet never existed. For example: > ZRANGE nonexistent 0 10 will also result in > "(error) ERR The server had an internal error please try again". > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9386) google-windows-geode-builder image doesn't properly delete geode directory after dependency caching
[ https://issues.apache.org/jira/browse/GEODE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9386: - Issue Type: Task (was: Bug) > google-windows-geode-builder image doesn't properly delete geode directory > after dependency caching > --- > > Key: GEODE-9386 > URL: https://issues.apache.org/jira/browse/GEODE-9386 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.4, 1.13.4, 1.14.0, 1.15.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9411) ExecutionHandlerContext.getExceptionResponse() should not close the client connection on IOException
[
https://issues.apache.org/jira/browse/GEODE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9411:
-
Labels: pull-request-available unreleased (was: pull-request-available
unable)
> ExecutionHandlerContext.getExceptionResponse() should not close the client
> connection on IOException
>
>
> Key: GEODE-9411
> URL: https://issues.apache.org/jira/browse/GEODE-9411
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> In {{ExecutionHandlerContext.getExceptionResponse()}} we always return a
> response of some kind to the client, except for if we hit an {{IOException}}
> during command execution, in which case we close the client connection and
> don't send any reply. This behaviour is leftover from the now-removed
> function execution approach that Radish was taking, so should also be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9377) Revert deploymentName on Deployment configuration object.
[ https://issues.apache.org/jira/browse/GEODE-9377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9377: - Labels: pull-request-available unreleased (was: pull-request-available) > Revert deploymentName on Deployment configuration object. > - > > Key: GEODE-9377 > URL: https://issues.apache.org/jira/browse/GEODE-9377 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh, management >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Revert the addition of deploymentName to Deployment to avoid serialization > issues with older versions that use fileName. Deployment name was added as > part of ticket GEODE-8705, to support a dropped feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9366) Redis SynchronizedStripeExecutor can throw IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9366:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis SynchronizedStripeExecutor can throw IndexOutOfBoundsException
>
>
> Key: GEODE-9366
> URL: https://issues.apache.org/jira/browse/GEODE-9366
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Saw the following issue being logged:
> {noformat}
> [warn 2021/06/08 08:25:48.005 PDT redisServergemfire1_host1_9978
> tid=0x79] Execution of Redis command HMSET
> \xac\xed\x00\x05t\x00 \xac\xed\x00\x05t\x00\x10lastAccessedTime
>
> \xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01y\xec:\xd0c
> \xac\xed\x00\x05t\x00\x13maxInactiveInterval \xac\xed\x00\x05sr\x00\x11ja
> va.lang.Integer\x12\xe2\xa0\xa4\xf7\x81\x878\x02\x00\x01I\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x00<
> \xac\xed\x00\x05t\x00\x19sessionAttr:Object_214669
> \xac\xed\x00\x05t\x00\rObject_214669 \xac\xed\x00\x05t\
> x00\x0ccreationTime
> \xac\xed\x00\x05sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x01y\xec:\xd0c
> failed: java.lang.ArrayIndexOutOfBoundsException: -11
> 52
> [error 2021/06/08 08:25:48.018 PDT redisServergemfire1_host1_9978
> tid=0x79] GeodeRedisServer-Unexpected error
> handler for [id: 0x7d55de8e, L:/10.32.109.109:21171 - R:/10.32.109.109:39854]
> java.lang.ArrayIndexOutOfBoundsException: -1152
> at
> org.apache.geode.redis.internal.executor.SynchronizedStripedExecutor.getSync(SynchronizedStripedExecutor.java:56)
> at
> org.apache.geode.redis.internal.executor.SynchronizedStripedExecutor.execute(SynchronizedStripedExecutor.java:44)
> at
> org.apache.geode.redis.internal.RegionProvider.execute(RegionProvider.java:136)
> at
> org.apache.geode.redis.internal.data.RedisDataCommandsFunctionExecutor.stripedExecute(RedisDataCommandsFunctionExecutor.java:48)
> at
> org.apache.geode.redis.internal.data.RedisHashCommandsFunctionExecutor.hset(RedisHashCommandsFunctionExecutor.java:42)
> at
> org.apache.geode.redis.internal.executor.hash.HMSetExecutor.executeCommand(HMSetExecutor.java:58)
> at
> org.apache.geode.redis.internal.RedisCommandType.executeCommand(RedisCommandType.java:353)
> at
> org.apache.geode.redis.internal.netty.Command.execute(Command.java:178)
> at
> org.apache.geode.redis.internal.netty.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:330)
> at
> org.apache.geode.redis.internal.netty.ExecutionHandlerContext.processCommandQueue(ExecutionHandlerContext.java:155)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9333) SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted may fail due to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9333:
-
Labels: testing (was: )
> SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted
> may fail due to IndexOutOfBoundsException
> -
>
> Key: GEODE-9333
> URL: https://issues.apache.org/jira/browse/GEODE-9333
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: testing
> Fix For: 1.15.0
>
>
> Seen in a PR pre-checkin test run:
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> java.lang.IndexOutOfBoundsException: Index -5 out of bounds for length 100
> at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.util.Objects.checkIndex(Objects.java:372)
> at java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.validateSessionAttributes(SessionsAndCrashesDUnitTest.java:179)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:170)
> {noformat}
> This occurs in the below block when {{totalUpdates}} is less than
> {{NUM_SESSIONS}}.
> {code:java}
> for (int i = totalUpdates - NUM_SESSIONS; i < totalUpdates; i++) {
> int sessionIdx = i % NUM_SESSIONS;
> String sessionId = sessionIds.get(sessionIdx);
> ...
> {code}
> Running the test locally with some trace logging added, it seems that
> {{totalUpdates}} is typically ~120, so if something were to cause updates to
> be 20% slower on a run of the test, this failure could show up. A solution
> might be to either await until at least {{NUM_SESSIONS}} updates have been
> performed by the updater threads, or to put in some logic to handle the case
> when {{totalUpdates}} is less than {{NUM_SESSIONS}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9317) ZADD/ZSCORE do not properly handle infinity
[ https://issues.apache.org/jira/browse/GEODE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9317: - Labels: pull-request-available unreleased (was: pull-request-available) > ZADD/ZSCORE do not properly handle infinity > --- > > Key: GEODE-9317 > URL: https://issues.apache.org/jira/browse/GEODE-9317 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Hale Bales >Priority: Critical > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > Native Redis accepts values like "inf", "+inf", "-infinity", etc. Currently > Radish considers these values invalid and returns "ERR value is not a valid > float". -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
[ https://issues.apache.org/jira/browse/GEODE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9343: - Labels: pull-request-available testing (was: pull-request-available) > Refactoring: move getInfo() method from INFO command to a TestHelper class > -- > > Key: GEODE-9343 > URL: https://issues.apache.org/jira/browse/GEODE-9343 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.15.0 > > > the getInfo() method is used throughout our tests to parse the data returned > by the INFO command. There is a lot of duplication of this implementation, > which is risky for future development. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9314) Redis CLUSTER NODES incorrect when primary buckets are moving
[ https://issues.apache.org/jira/browse/GEODE-9314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9314: - Labels: pull-request-available unreleased (was: pull-request-available) > Redis CLUSTER NODES incorrect when primary buckets are moving > - > > Key: GEODE-9314 > URL: https://issues.apache.org/jira/browse/GEODE-9314 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > When buckets are moving the CLUSTER NODES command may produce incorrect > results - specifically the node host/port information may be > duplicated/incorrect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9311) It is possible that JedisCluster client may still retry if the Geode Redis server it is connected to shuts down
[ https://issues.apache.org/jira/browse/GEODE-9311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9311: - Labels: unreleased (was: ) > It is possible that JedisCluster client may still retry if the Geode Redis > server it is connected to shuts down > --- > > Key: GEODE-9311 > URL: https://issues.apache.org/jira/browse/GEODE-9311 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Labels: unreleased > Fix For: 1.15.0 > > > Even after the issue (GEODE-9310) is addressed, the retry issue may still > occur if the JedisCluster client is connected to the node is being shut down. > Here is a test run result: > vm2 gets the command: > [vm2] [warn 2021/05/25 16:01:41.479 PDT server-2 > tid=0x64] Executing Redis command: ZREM key member1-212 member1-211 > member1-214 member1-213 member1-210 member1-209 member1-208 member1-205 > member1-204 > *** command is executed on the primary *** > [vm2] [warn 2021/05/25 16:01:41.503 PDT server-2 Processor2> tid=0x51] bucket region is > BucketRegion[path='/__PR/_B__REDIS__DATA_123;serial=200;primary=true] key key > [vm2] java.lang.Exception > [vm2] at > org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:533) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1213) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:3024) > [vm2] at > org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2236) > [vm2] at > org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5586) > And distributed to replica (vm1): > vm1] [warn 2021/05/25 16:01:41.518 PDT server-1 192.168.0.14(server-2:83136):41002 shared ordered sender uid=7 local > port=58643 remote port=53459> tid=0x59] membersRemoveAll invoked > [vm1] java.lang.Exception > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.membersRemoveAll(RedisSortedSet.java:175) > [vm1] at > org.apache.geode.redis.internal.data.RedisSortedSet.applyDelta(RedisSortedSet.java:89) > [vm1] at > org.apache.geode.redis.internal.data.AbstractRedisData.fromDelta(AbstractRedisData.java:193) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1841) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.setNewValueInRegion(EntryEventImpl.java:1696) > [vm1] at > org.apache.geode.internal.cache.EntryEventImpl.putExistingEntry(EntryEventImpl.java:1643) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.updateEntry(RegionMapPut.java:485) > [vm1] at > org.apache.geode.internal.cache.map.RegionMapPut.createOrUpdateEntry(RegionMapPut.java:256) > vm2 is bounced: > [vm2] [info 2021/05/25 16:01:41.526 PDT server-2 Connection(1)-192.168.0.14> tid=0x14] Got result: 83136 > [vm2] from org.apache.geode.test.dunit.VM$$Lambda$370/1141741369.call with 0 > args on object: > org.apache.geode.test.dunit.VM$$Lambda$370/1141741369@68ecd55a (took 0 ms) > [info 2021/05/25 16:01:41.527 PDT tid=0x36] Bouncing 2 old > pid is 83136 and version is 10240.0.0 > The JedisCluster client did not get response back (possibly detects > connection is gone), and it does retry again, as the test failed with > following: > java.util.concurrent.ExecutionException: > redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more > cluster attempts left. > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.redis.internal.executor.sortedset.ZRemDUnitTest.zRemCanRemoveMembersFromSortedSetDuringPrimaryIsCrashed(ZRemDUnitTest.java:177) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.j
[jira] [Updated] (GEODE-9304) Make RedisSortedSet's measurement of byes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9304: - Labels: pull-request-available unreleased (was: pull-request-available) > Make RedisSortedSet's measurement of byes in use more accurate > -- > > Key: GEODE-9304 > URL: https://issues.apache.org/jira/browse/GEODE-9304 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > The current calculation of bytes in use by RedisSortedSet is inaccurate, and > needs to be improved. Once a strategy for size calculation for classes using > Object2ObjectCustomHash and OrderStatisticsTree has been decided, it should > be implemented for this data type. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9218) Geode has tests for TLSv1.1 which is disabled by default now
[ https://issues.apache.org/jira/browse/GEODE-9218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9218: - Labels: pull-request-available testing (was: pull-request-available) > Geode has tests for TLSv1.1 which is disabled by default now > > > Key: GEODE-9218 > URL: https://issues.apache.org/jira/browse/GEODE-9218 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available, testing > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > According to the [Oracle JRE/JDK cryptographic > roadmap|https://java.com/en/jre-jdk-cryptoroadmap.html#releasedChangesTable], > TLSv1 and TLSv1.1 are disabled by default as of 11.0.11+9 and 8u291b10. This > causes TLSv1.1 tests to fail. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9287) Eliminate use of platform dependent String.getBytes() and new String(bytes) calls in redis
[ https://issues.apache.org/jira/browse/GEODE-9287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9287: - Labels: pull-request-available unreleased (was: pull-request-available) > Eliminate use of platform dependent String.getBytes() and new String(bytes) > calls in redis > --- > > Key: GEODE-9287 > URL: https://issues.apache.org/jira/browse/GEODE-9287 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.15.0 > > > We have a number of places that call either String.getBytes() or new > String(bytes) in the redis module. > These methods may produce different output depending on the underlying > platforms default encoding. > We should switch these places to call use our standard Coder.stringToBytes > and bytesToString methods. Those methods should use UTF-8 encoding, eg > String.getBytes(StandardCharsets.UTF-8). > We should eliminate conversions between bytes and strings as much as possible > on critical path code. In particular, our parser should have constants for > the byte[] values of all of the static strings in the commands. > We may want to consider encoding error responses as ASCII, rather than UTF-8, > for more compatibility with different clients if an error message > accidentally contains a non-ascii character. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9208:
-
Issue Type: Task (was: Bug)
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Task
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9192) test-container docker image is unstable due to dependencies
[ https://issues.apache.org/jira/browse/GEODE-9192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9192: - Issue Type: Task (was: Bug) > test-container docker image is unstable due to dependencies > --- > > Key: GEODE-9192 > URL: https://issues.apache.org/jira/browse/GEODE-9192 > Project: Geode > Issue Type: Task > Components: ci >Affects Versions: 1.12.2, 1.13.2 >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > buildpack-scm, a docker image that our test container relies on, has become > unstable. This has caused problems for mass-test. Replace the base image with > ubuntu. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9153) alpine-tools image fails to build
[ https://issues.apache.org/jira/browse/GEODE-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9153: - Issue Type: Task (was: Bug) > alpine-tools image fails to build > - > > Key: GEODE-9153 > URL: https://issues.apache.org/jira/browse/GEODE-9153 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.2, 1.13.3, 1.14.0, 1.15.0 > > > The alpine-tools docker image fails to build properly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9062) DataSerializableJUnitTest fails in StressTest task
[
https://issues.apache.org/jira/browse/GEODE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9062:
-
Labels: pull-request-available testing (was: pull-request-available)
> DataSerializableJUnitTest fails in StressTest task
> --
>
> Key: GEODE-9062
> URL: https://issues.apache.org/jira/browse/GEODE-9062
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.15.0
>
>
> DataSerializableJUnitTest is failing if executed using the "repeatUnitTest"
> gradle task. I dont know what is causing this failure, but I got the error
> when verifying a PR ( [https://concourse.apachegeode-ci.info/builds/17155] )
> and I realized it is failing in develop branch too.
> {code}
> ~/git/apache/geode (develop) $ ./gradlew geode-core:repeatUnitTest
> --tests=DataSerializableJUnitTest
> ...
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS2 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS2(DataSerializableJUnitTest.java:2284)
> org.apache.geode.internal.DataSerializableJUnitTest > testUDDS4 FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testUDDS4(DataSerializableJUnitTest.java:2307)
> org.apache.geode.internal.DataSerializableJUnitTest > testSupportedClasses
> FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertFalse(Assert.java:65)
> at org.junit.Assert.assertFalse(Assert.java:75)
> at
> org.apache.geode.internal.DataSerializableJUnitTest.testSupportedClasses(DataSerializableJUnitTest.java:2260)
> 11100 tests completed, 297 failed, 200 skipped
> > Task :geode-core:repeatUnitTest FAILED
> > Task :combineReports
> All test reports at /home/alb3rtobr/git/apache/geode/build/reports/combined
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':geode-core:repeatUnitTest'.
> > There were failing tests. See the report at:
> > file:///home/alb3rtobr/git/apache/geode/geode-core/build/reports/repeatUnitTest/index.html
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 1m 8s
> 36 actionable tasks: 2 executed, 34 up-to-date
> ~/git/apache/geode (develop) $ git log -n 1
> commit a45dbf94de2f35b869a3dd0e1cf945f5282e2fd0 (HEAD -> develop,
> origin/develop, origin/HEAD)
> Author: Mario Kevo <48509719+mk...@users.noreply.github.com>
> Date: Wed Mar 24 10:25:29 2021 +0100
> GEODE-8962: add an option to escape dollar($) character in the query (#6044)
>
> * GEODE-8962: add an option to escape dollar($) character in the query
> {code}
> Three tests are failing: testSupportedClasses, testUDDS2 and testUDDS4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9050) Redis test fails with Netty 4.1.60 and later
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9050:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis test fails with Netty 4.1.60 and later
>
>
> Key: GEODE-9050
> URL: https://issues.apache.org/jira/browse/GEODE-9050
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> {{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
> [fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
> reliably, on both Linux and Windows, if I [bump
> Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
> from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
> latest versions of our 3rd-party dependencies but breaking this out
> separately so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9046) Refactor references to the subclass from superclasses in geode-redis
[ https://issues.apache.org/jira/browse/GEODE-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9046: - Labels: pull-request-available unreleased (was: pull-request-available) > Refactor references to the subclass from superclasses in geode-redis > > > Key: GEODE-9046 > URL: https://issues.apache.org/jira/browse/GEODE-9046 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Currently, in geode-redis > * NullRedisString is referenced from RedisString > * NullRedisHash is referenced from RedisHash > * NullRedisSet is referenced from RedisSet > These Null redis data structures need to be moved to a separate class to > avoid the superclass referencing subclasses. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9086) Documentation for DECRBY command
[ https://issues.apache.org/jira/browse/GEODE-9086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9086: - Component/s: docs > Documentation for DECRBY command > > > Key: GEODE-9086 > URL: https://issues.apache.org/jira/browse/GEODE-9086 > Project: Geode > Issue Type: Bug > Components: docs, redis >Reporter: Nabarun Nag >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Ensure that there is sufficient documentation for the DECRBY command in the > compatible with redis module. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9084) Remove Redis GFSH command
[ https://issues.apache.org/jira/browse/GEODE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9084: - Labels: blocks-1.14.0 pull-request-available unreleased (was: blocks-1.14.0 pull-request-available) > Remove Redis GFSH command > - > > Key: GEODE-9084 > URL: https://issues.apache.org/jira/browse/GEODE-9084 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Things have changed since we first introduced the concept of Unsupported vs > Unimplemented. > _Original Idea:_ Allow users to use the unsupported commands, log which one's > were being used. Use this information to help drive future iterations. > Given: > * new direction of the product (Tanzu Cache) > * Safety for customers not to get into a bad situation > * Confusion for support, our team, the field > We should remove the ability to use the unsupported commands unless the > system property 'enable-unsupported-commands' is set. > > End result: > * The 'redis' gfsh command is no longer present > * Remove the documentation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9006) MemoryStatsNativeRedisAcceptanceTest CI failure
[
https://issues.apache.org/jira/browse/GEODE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-9006:
-
Labels: pull-request-available testing (was: pull-request-available)
> MemoryStatsNativeRedisAcceptanceTest CI failure
> ---
>
> Key: GEODE-9006
> URL: https://issues.apache.org/jira/browse/GEODE-9006
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Ray Ingles
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, testing
> Fix For: 1.14.0, 1.15.0
>
>
> CI failure:
> {{org.apache.geode.redis.internal.executor.server.MemoryStatsNativeRedisAcceptanceTest
> > usedMemory_shouldReflectActualMemoryUsage FAILED
> java.lang.AssertionError:
> Expecting:
> 854912L
> to be greater than:
> 855176L}}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/51]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-9019: - Labels: blocks-1.14.0 pull-request-available unreleased (was: blocks-1.14.0 pull-request-available) > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available, unreleased > Fix For: 1.14.0, 1.15.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8950: - Labels: testing (was: ) > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: testing > Fix For: 1.14.0, 1.15.0 > > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8945) deploy pipelines for new support branch should not create mass test run pipeline
[ https://issues.apache.org/jira/browse/GEODE-8945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8945: - Issue Type: Task (was: Bug) > deploy pipelines for new support branch should not create mass test run > pipeline > > > Key: GEODE-8945 > URL: https://issues.apache.org/jira/browse/GEODE-8945 > Project: Geode > Issue Type: Task > Components: release >Affects Versions: 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > only develop needs mass test enabled -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available test (was: GeodeOperationAPI pull-request-available) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, test > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-8644: - Labels: GeodeOperationAPI pull-request-available testing (was: GeodeOperationAPI pull-request-available test) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, testing > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8859:
-
Labels: pull-request-available unreleased (was: pull-request-available)
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available, unreleased
> Fix For: 1.15.0
>
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8616:
-
Labels: GeodeOperationAPI flaky-test pull-request-available testing (was:
GeodeOperationAPI flaky-test pull-request-available)
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1, 1.13.7, 1.14.3, 1.15.0
>Reporter: Donal Evans
>Assignee: Nabarun Nag
>Priority: Major
> Labels: GeodeOperationAPI, flaky-test, pull-request-available,
> testing
> Fix For: 1.15.0, 1.16.0
>
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz,
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8097) ClientClusterManagementServiceTest expects 1 callback but gets 295
[
https://issues.apache.org/jira/browse/GEODE-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-8097:
-
Labels: GeodeOperationAPI blocks-1.14.0 pull-request-available testing
(was: GeodeOperationAPI blocks-1.14.0 pull-request-available)
> ClientClusterManagementServiceTest expects 1 callback but gets 295
> --
>
> Key: GEODE-8097
> URL: https://issues.apache.org/jira/browse/GEODE-8097
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0,
> pull-request-available, testing
> Fix For: 1.14.0, 1.15.0
>
>
> CI test failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/138#A
> {code}
> org.apache.geode.management.internal.ClientClusterManagementServiceTest >
> getOperationCallsSubmitMessageAndReturnsFuture FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.ClientClusterManagementServiceTest
> clusterManagementServiceTransport.submitMessageForGetOperation(
>
> same(org.apache.geode.management.operation.RebalanceOperation@6d6b2db0),
> same("opId")
> );
> Wanted 1 time:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementServiceTest.lambda$getOperationCallsSubmitMessageAndReturnsFuture$1(ClientClusterManagementServiceTest.java:170)
> But was 295 times:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> …
> {code}
> Ran it 100 times in IntelliJ with no failures.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
