[jira] [Commented] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515685#comment-17515685
]
ASF subversion and git services commented on GEODE-10191:
-
Commit 3a8044aeec9d492182c4bf1a4a311fdc382a393d in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a8044a ]
GEODE-10191: Radish RENAME and RESTORE create notification events (#7537)
- Both of these commands have the ability to create events to satisfy
BLPOP.
- Introduce a NotificationEvent enum which is passed to fireEvent.
- Previously the RedisCommandType was being passed, but this does not
work for RENAME which creates RENAME_FROM and RENAME_TO events. In the
future, other commands will need to create multiple events too.
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-10191:
--
Assignee: Jens Deppe
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10191.
Fix Version/s: 1.15.0
Resolution: Fixed
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7710:
Assignee: (was: Kirk Lund)
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, needsTriage,
> pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515634#comment-17515634 ] Geode Integration commented on GEODE-10151: --- Seen in [test-examples #293|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/293]. > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515631#comment-17515631 ] ASF GitHub Bot commented on GEODE-10151: upthewaterspout merged pull request #114: URL: https://github.com/apache/geode-examples/pull/114 -- 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 > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515630#comment-17515630 ] ASF subversion and git services commented on GEODE-10151: - Commit 6411438149dfa88300c0873654b6aa9780b3991f in geode-examples's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=6411438 ] GEODE-10151: Extract redis distribution The redis example needs to include the redis distribution on the classpath of the geode server. Adding support in the build to extract the redis distribution, and modifying the start scripts for this example to include geode-for-redis on the classpath. > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary
[
https://issues.apache.org/jira/browse/GEODE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515625#comment-17515625
]
ASF subversion and git services commented on GEODE-10171:
-
Commit fb17fe41adb877aabd96aa4fc95509c4b652dc0b in geode's branch
refs/heads/develop from Kris10
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb17fe4 ]
GEODE-10171: Update versioning for no-op operations (#7527)
Modified lrem to not update versioning if nothing was removed from the
list.
> AbstractRedisData version being incremented for no-op operations can lead to
> delta not being applied on secondary
> -
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Kristen
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> For SADD, which may or may not modify the data in the region depending on
> whether the member being added is already present in the set, the version in
> AbstractRedisData is updated regardless of whether a Delta is sent to the
> secondary. This can lead to the version on the primary wrapping around to be
> equal to the version on the secondary, which means that if a delta is sent,
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
> String originalMember = "fixedMemberName";
> String key = clusterStartUp.getKeyOnServer("tag", 1);
>
> // Version of primary = 0
> // Version of secondary = 0
> jedis.sadd(key, originalMember);
> // No changes are made to the set, since adding an already existing member
> doesn't modify it
> // Version of primary wraps around back to -1
> // Version of secondary doesn't change because we don't send a delta
> for (int i = 0; i < 255; ++i) {
> jedis.sadd(key, originalMember);
> }
> String newMember = "aNewMemberName";
> // Version of primary = 0
> // Version of secondary = 0, delta is not applied
> jedis.sadd(key, newMember);
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> clusterStartUp.crashVM(1); // kill primary server
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> } {code}
> The example here uses SADD, but potentially, any command that can be a no-op
> and uses a versioned Delta is at risk of hitting this. All commands should be
> checked to ensure they're not vulnerable to this bug.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10207) check log levels for gfsh commands
Dave Barnes created GEODE-10207: --- Summary: check log levels for gfsh commands Key: GEODE-10207 URL: https://issues.apache.org/jira/browse/GEODE-10207 Project: Geode Issue Type: Sub-task Components: docs Affects Versions: 1.14.4 Reporter: Dave Barnes Community member Tod Morrison suggests checking log levels for gfsh commands `alter runtime` and `change loglevel`. The levels don’t look right: The new log level. This option is required and you must specify a value. Valid values are: ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, OFF. (Default is INFO) See https://geode.apache.org/docs/guide/114/managing/logging/setting_up_logging.html, which shows valid choices of `severe`, `error`, `warning`, `info`, `config`, and `fine`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10188) AvailablePortHelperIntegrationTest > initializeUniquePortRange_returnSamePortsForSameRange gets different ports on subsequent tries
[
https://issues.apache.org/jira/browse/GEODE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515609#comment-17515609
]
Geode Integration commented on GEODE-10188:
---
Seen on support/1.13 in [integration-test-openjdk11
#37|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/integration-test-openjdk11/builds/37]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0670/test-results/integrationTest/1648664514/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0670/test-artifacts/1648664514/integrationtestfiles-openjdk11-1.13.9-build.0670.tgz].
> AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange gets different ports on
> subsequent tries
> ---
>
> Key: GEODE-10188
> URL: https://issues.apache.org/jira/browse/GEODE-10188
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.9
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14294054]
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange(useMembershipPortRange=true)
> FAILED
> org.junit.ComparisonFailure: expected:<[460[10, 46011, 4601]2]> but
> was:<[460[00, 46001, 4600]2]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_returnSamePortsForSameRange(AvailablePortHelperIntegrationTest.java:322)
> 4023 tests completed, 1 failed, 82 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-results/integrationTest/1648509410/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-artifacts/1648509410/integrationtestfiles-openjdk11-1.13.9-build.0668.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10188) AvailablePortHelperIntegrationTest > initializeUniquePortRange_returnSamePortsForSameRange gets different ports on subsequent tries
[
https://issues.apache.org/jira/browse/GEODE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515610#comment-17515610
]
Geode Integration commented on GEODE-10188:
---
Seen on support/1.13 in [acceptance-test-openjdk11
#38|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/38]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0671/test-results/acceptanceTest/1648762889/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0671/test-artifacts/1648762889/acceptancetestfiles-openjdk11-1.13.9-build.0671.tgz].
> AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange gets different ports on
> subsequent tries
> ---
>
> Key: GEODE-10188
> URL: https://issues.apache.org/jira/browse/GEODE-10188
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.9
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14294054]
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange(useMembershipPortRange=true)
> FAILED
> org.junit.ComparisonFailure: expected:<[460[10, 46011, 4601]2]> but
> was:<[460[00, 46001, 4600]2]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_returnSamePortsForSameRange(AvailablePortHelperIntegrationTest.java:322)
> 4023 tests completed, 1 failed, 82 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-results/integrationTest/1648509410/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-artifacts/1648509410/integrationtestfiles-openjdk11-1.13.9-build.0668.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-6489) CI Failures with testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515602#comment-17515602
]
Geode Integration commented on GEODE-6489:
--
Seen in [distributed-test-openjdk8
#263|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/263]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1051/test-results/distributedTest/1648761552/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1051/test-artifacts/1648761552/distributedtestfiles-openjdk8-1.15.0-build.1051.tgz].
> CI Failures with testDistributedDeadlock
>
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.14.0, 1.15.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515586#comment-17515586 ] ASF GitHub Bot commented on GEODE-10151: upthewaterspout opened a new pull request #114: URL: https://github.com/apache/geode-examples/pull/114 The redis example needs to include the redis distribution on the classpath of the geode server. Adding support in the build to extract the redis distribution, and modifying the start scripts for this example to include geode-for-redis on the classpath. -- 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 > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515585#comment-17515585
]
Geode Integration commented on GEODE-9889:
--
Seen on support/1.14 in [integration-test-openjdk11
#43|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/integration-test-openjdk11/builds/43]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0947/test-results/integrationTest/1648756705/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0947/test-artifacts/1648756705/integrationtestfiles-openjdk11-1.14.5-build.0947.tgz].
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10184) CI failure on windows: non-zero exit status on gfsh command in DeployWithLargeJarTest > deployLargeSetOfJars
[
https://issues.apache.org/jira/browse/GEODE-10184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515580#comment-17515580
]
Patrick Johnsn commented on GEODE-10184:
The issue seems to come from the ControlFileWatchdog not being able to read the
PID from the vf.gf.server.status file because it's either empty or missing,
probably empty. I haven't been able to reproduce the issue other than by
manually deleting the vf.gf.server.status file, which doesn't tell us much. The
failure's test output doesn't indicate why vf.gf.server.status is
blank/missing, so without being able to reproduce it, I can't figure out what
caused it to fail.
> CI failure on windows: non-zero exit status on gfsh command in
> DeployWithLargeJarTest > deployLargeSetOfJars
>
>
> Key: GEODE-10184
> URL: https://issues.apache.org/jira/browse/GEODE-10184
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: needsTriage
>
> Deploy large jar test fails due to non-zero exit status on gfsh command on
> windows
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291025]
>
> {noformat}
> > Task :geode-assembly:acceptanceTest
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e66e7d3e01750dd9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-beanutils-1.9.4.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-codec-1.15.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-collections-3.2.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-digester-2.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-io-2.11.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-lang3-3.12.0.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-logging-1.2.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-modeler-2.0.1.jar,C:\\Users\\geode\\geode\\geode-assembly\\build\\install\\apache-geode\\lib\\commons-validator-1.7.jar]]
>
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> 176 tests completed, 1 failed, 18 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/acceptanceTest/1648482211/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648482211/windows-acceptancetestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10191:
---
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0)
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
[ https://issues.apache.org/jira/browse/GEODE-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515552#comment-17515552 ] ASF subversion and git services commented on GEODE-10141: - Commit 59af2c83865dcea5efd4760c0fa4c3012fb3ad7f in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=59af2c8 ] GEODE-10141: remove test expectation of toString format (#7525) Test now asks the GMSJoinLeave for its locators and validates that they are in the exception message instead of having a test expectation of how InetAddress will be formatted in this exception. > GMSJoinLeaveJUnitTest is overly specific about the expected exception message > - > > Key: GEODE-10141 > URL: https://issues.apache.org/jira/browse/GEODE-10141 > Project: Geode > Issue Type: Improvement > Components: membership, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > `GMSJoinLeave` throws the correct exception type, with a message correctly > describing its inability to connect to the locators at the specified > unresolved addresses. But the test's assertion is overly specific about the > description of an unresolved address, and fails on JDK 17. > In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` > returned `"hostname:port"`. Starting with JDK 14 it returns > `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
[ https://issues.apache.org/jira/browse/GEODE-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10141. -- Fix Version/s: 1.15.0 Resolution: Fixed > GMSJoinLeaveJUnitTest is overly specific about the expected exception message > - > > Key: GEODE-10141 > URL: https://issues.apache.org/jira/browse/GEODE-10141 > Project: Geode > Issue Type: Improvement > Components: membership, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > `GMSJoinLeave` throws the correct exception type, with a message correctly > describing its inability to connect to the locators at the specified > unresolved addresses. But the test's assertion is overly specific about the > description of an unresolved address, and fails on JDK 17. > In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` > returned `"hostname:port"`. Starting with JDK 14 it returns > `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
[ https://issues.apache.org/jira/browse/GEODE-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10141: --- Labels: Java17 pull-request-available (was: Java17) > GMSJoinLeaveJUnitTest is overly specific about the expected exception message > - > > Key: GEODE-10141 > URL: https://issues.apache.org/jira/browse/GEODE-10141 > Project: Geode > Issue Type: Improvement > Components: membership, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > > `GMSJoinLeave` throws the correct exception type, with a message correctly > describing its inability to connect to the locators at the specified > unresolved addresses. But the test's assertion is overly specific about the > description of an unresolved address, and fails on JDK 17. > In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` > returned `"hostname:port"`. Starting with JDK 14 it returns > `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515548#comment-17515548 ] ASF subversion and git services commented on GEODE-10201: - Commit f494989b82040f4921571216ede00ddb46825944 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f494989 ] GEODE-10201: Bump spring from 5.2.15 to 5.2.20 see https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches, so 5.2.20 is probably a better choice for > branches still on spring 5.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515546#comment-17515546 ] ASF subversion and git services commented on GEODE-10201: - Commit ccd57d5bc3c2d725e377434f3db48ed31048665b in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccd57d5 ] GEODE-10201: Bump spring from 5.2.15 to 5.2.20 (#7535) see https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches, so 5.2.20 is probably a better choice for > branches still on spring 5.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-10201. -- Fix Version/s: 1.12.10 1.13.9 1.14.5 1.15.0 Resolution: Fixed > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches, so 5.2.20 is probably a better choice for > branches still on spring 5.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-10201: Assignee: Owen Nichols > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches, so 5.2.20 is probably a better choice for > branches still on spring 5.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10201: - Description: spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on different support branches, so 5.2.20 is probably a better choice for branches still on spring 5.2 (was: spring 5.3.17 is preferred. currently we have a mix of 5.2 and 5.3 on different support branches.) > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > spring 5.3.18 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches, so 5.2.20 is probably a better choice for > branches still on spring 5.2 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515538#comment-17515538 ] ASF subversion and git services commented on GEODE-10201: - Commit d6564a2dfe8de1c7454ac9025e5023b44a6ef172 in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d6564a2 ] GEODE-10201: Bump spring from 5.3.8 to 5.3.18 (#7531) see https://github.com/spring-projects/spring-framework/issues/24434 > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > spring 5.3.17 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10201) bump spring to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515536#comment-17515536 ] ASF subversion and git services commented on GEODE-10201: - Commit 649616091bd3868ce7c8523acca42b22f4414ed5 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6496160 ] GEODE-10201: Bump spring from 5.3.16 to 5.3.18 (#7524) * GEODE-10201: Bump spring dependency versions Geode endeavors to update to the latest version of 3rd-party dependencies on develop wherever possible. Doing so increases the shelf life of releases and increases security and reliability. Doing so regularly makes the occasional hiccups this can cause easier to pinpoint and address. Dependency bumps in this batch: * Bump spring from 5.3.16 to 5.3.18 * Bump spring-boot-starter from 2.6.4 to 2.6.5 > bump spring to recommended version > -- > > Key: GEODE-10201 > URL: https://issues.apache.org/jira/browse/GEODE-10201 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > spring 5.3.17 is preferred. currently we have a mix of 5.2 and 5.3 on > different support branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515508#comment-17515508
]
ASF subversion and git services commented on GEODE-10196:
-
Commit cebf1f4fd9e1a1353223fefef2b94d21bd7cf45a in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cebf1f4 ]
GEODE-10196: now checks if msg contains "Connection reset" (#7528)
The test now looks for "Connection reset" instead of "Connection reset by peer"
> HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
> ---
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandle
[jira] [Resolved] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10196.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
> ---
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.interna
[jira] [Created] (GEODE-10206) Geode assumes CMS garbage collector, which JDK 17 lacks
Dale Emery created GEODE-10206: -- Summary: Geode assumes CMS garbage collector, which JDK 17 lacks Key: GEODE-10206 URL: https://issues.apache.org/jira/browse/GEODE-10206 Project: Geode Issue Type: Improvement Components: core, docs, gfsh Affects Versions: 1.15.0 Reporter: Dale Emery Several places in Geode code and documentation assume that Concurrent Mark Sweet (CMS) garbage collector exists, and that these VM arguments are meaningful: - -XX:+UseConcMarkSweepGC - -XX:CMSInitiatingOccupancyFraction The CMS garbage collector is not available on JDK 17. JDK 17 warns that it does not recognize these arguments. These production classes rely on CMS args at runtime: - extensions/geode-modules: ResourceManagerValidator.validateSunArguments() recommends configuring the CMS args. - geode-gfsh: StartMemberUtils passes the CMS args when max heap is set. These test classes use the CMS args at runtime: - geode-for-redis: OutOfMemoryDUnitTest passes a CMSInitiatingOccupancyFraction arg when starting a server. User-facing Javadoc comments on these classes refer to the CMS args: - geode-core: EvictionAttributes - geode-core: ResourceManager Code comments in these classes refer to the CMS args: - geode-modules: AbstractCache These properties files in geode-modules-assembly define or refer to the CMS args: - scripts/setenv.properties - tcserver/geode-cs/configuration-prompts.properties - tcserver/geode-p2p/configuration-prompts.properties These documentation files in geode-docs refer to the CMS args: - configuring/running/running_the_cacheserver.html.md.erb - managing/heap_use/heap_management.html.md.erb - managing/monitor_tune/system_member_performance_garbage.html.md.erb -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10206) Geode assumes CMS garbage collector, which JDK 17 lacks
[ https://issues.apache.org/jira/browse/GEODE-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-10206: --- Labels: Java17 (was: ) > Geode assumes CMS garbage collector, which JDK 17 lacks > --- > > Key: GEODE-10206 > URL: https://issues.apache.org/jira/browse/GEODE-10206 > Project: Geode > Issue Type: Improvement > Components: core, docs, gfsh >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17 > > Several places in Geode code and documentation assume that Concurrent Mark > Sweet (CMS) garbage collector exists, and that these VM arguments are > meaningful: > - -XX:+UseConcMarkSweepGC > - -XX:CMSInitiatingOccupancyFraction > The CMS garbage collector is not available on JDK 17. JDK 17 warns that it > does not recognize these arguments. > These production classes rely on CMS args at runtime: > - extensions/geode-modules: ResourceManagerValidator.validateSunArguments() > recommends configuring the CMS args. > - geode-gfsh: StartMemberUtils passes the CMS args when max heap is set. > These test classes use the CMS args at runtime: > - geode-for-redis: OutOfMemoryDUnitTest passes a > CMSInitiatingOccupancyFraction arg when starting a server. > User-facing Javadoc comments on these classes refer to the CMS args: > - geode-core: EvictionAttributes > - geode-core: ResourceManager > Code comments in these classes refer to the CMS args: > - geode-modules: AbstractCache > These properties files in geode-modules-assembly define or refer to the CMS > args: > - scripts/setenv.properties > - tcserver/geode-cs/configuration-prompts.properties > - tcserver/geode-p2p/configuration-prompts.properties > These documentation files in geode-docs refer to the CMS args: > - configuring/running/running_the_cacheserver.html.md.erb > - managing/heap_use/heap_management.html.md.erb > - managing/monitor_tune/system_member_performance_garbage.html.md.erb -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10205:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
Max Hufnagel created GEODE-10205:
Summary: getDiskStore method described in the docs does not exist
in the Java API
Key: GEODE-10205
URL: https://issues.apache.org/jira/browse/GEODE-10205
Project: Geode
Issue Type: Bug
Components: docs
Affects Versions: 1.14.4
Reporter: Max Hufnagel
h2. Description
Looking at document
[https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
It states:
Compact the logs for a single online disk store through the API, with the
forceCompaction method. This method first rolls the oplogs and then compacts
them. Example:
myCache.getDiskStore("myDiskStore").forceCompaction();
In the Java API there is no getDiskStore method at all.
Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10205) getDiskStore method described in the docs does not exist in the Java API
[
https://issues.apache.org/jira/browse/GEODE-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10205:
--
Labels: needsTriage (was: )
> getDiskStore method described in the docs does not exist in the Java API
>
>
> Key: GEODE-10205
> URL: https://issues.apache.org/jira/browse/GEODE-10205
> Project: Geode
> Issue Type: Bug
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Priority: Major
> Labels: needsTriage
>
> h2. Description
>
> Looking at document
> [https://geode.apache.org/docs/guide/114/managing/disk_storage/compacting_disk_stores.html|https://gemfire.docs.pivotal.io/910/geode/managing/disk_storage/compacting_disk_stores.html]
> It states:
> Compact the logs for a single online disk store through the API, with the
> forceCompaction method. This method first rolls the oplogs and then compacts
> them. Example:
> myCache.getDiskStore("myDiskStore").forceCompaction();
> In the Java API there is no getDiskStore method at all.
> Also in the DiskStore Interface it says to use Cache.FindDiskStore(STRING) to
> find get an existing DiskStore object.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10204) Add test cases for SizeableByteArray
Ray Ingles created GEODE-10204: -- Summary: Add test cases for SizeableByteArray Key: GEODE-10204 URL: https://issues.apache.org/jira/browse/GEODE-10204 Project: Geode Issue Type: Test Components: redis Reporter: Ray Ingles For example, clearSublist() was added for LTRIM support and needs tests. Any public method without tests should have coverage. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515429#comment-17515429 ] Geode Integration commented on GEODE-10151: --- Seen in [test-examples #291|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/291]. > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515430#comment-17515430 ] Geode Integration commented on GEODE-10151: --- Seen in [test-examples #292|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/292]. > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10151) Make geode-for-redis an optional dependency of a geode server
[ https://issues.apache.org/jira/browse/GEODE-10151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reopened GEODE-10151: --- Re-opening because the examples build is failing due to this change - https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/291 > Make geode-for-redis an optional dependency of a geode server > - > > Key: GEODE-10151 > URL: https://issues.apache.org/jira/browse/GEODE-10151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The geode-for-redis module and its related dependencies are on the classpath > of the server by default when starting a server with gfsh start server or > using the geode dependencies jar. > We should make the module an optional dependencies, like some of our other > extensions (for example, the tomcat http session modules). This would allow a > user to choose if they want redis on the classpath or not. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9955) Implement RPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515420#comment-17515420 ] ASF subversion and git services commented on GEODE-9955: Commit 6806179b67bac90d18aa23adcb68413942433636 in geode's branch refs/heads/develop from Kris10 [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6806179 ] GEODE-9955: Add RPUSHX command (#7507) This implements a version of the Redis RPUSHX command, which is used for list data types. Associated tests were also added. For a list stored at a key, rpushx adds the specified element to the tail of the list. If the key does not exist, no operation will be performed. > Implement RPUSHX > > > Key: GEODE-9955 > URL: https://issues.apache.org/jira/browse/GEODE-9955 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > Implement the [RPUSHX|https://redis.io/commands/rpushx] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10180) Set endpoint validation for the gateway using the legacy configuration
[ https://issues.apache.org/jira/browse/GEODE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami resolved GEODE-10180. Fix Version/s: 1.15.0 Resolution: Fixed > Set endpoint validation for the gateway using the legacy configuration > -- > > Key: GEODE-10180 > URL: https://issues.apache.org/jira/browse/GEODE-10180 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Kamilla Aslami >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > SSLConfigurationFactory.configureLegacyGatewaySSL() should configure endpoint > validation if it is specified in distribution configuration properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10180) Set endpoint validation for the gateway using the legacy configuration
[ https://issues.apache.org/jira/browse/GEODE-10180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami reassigned GEODE-10180: -- Assignee: Kamilla Aslami > Set endpoint validation for the gateway using the legacy configuration > -- > > Key: GEODE-10180 > URL: https://issues.apache.org/jira/browse/GEODE-10180 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Kamilla Aslami >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > > SSLConfigurationFactory.configureLegacyGatewaySSL() should configure endpoint > validation if it is specified in distribution configuration properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9889:
-
Assignee: Jens Deppe (was: Hale Bales)
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515365#comment-17515365
]
Geode Integration commented on GEODE-9889:
--
Seen on support/1.14 in [integration-test-openjdk11
#42|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/integration-test-openjdk11/builds/42]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0946/test-results/integrationTest/1648716015/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0946/test-artifacts/1648716015/integrationtestfiles-openjdk11-1.14.5-build.0946.tgz].
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
