[jira] [Resolved] (GEODE-10277) Exception thrown when checking gatewaySender EventQueueSize, while restarting gateway sender with clean queue option
[ https://issues.apache.org/jira/browse/GEODE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-10277. -- Fix Version/s: 1.15.0 Resolution: Fixed > Exception thrown when checking gatewaySender EventQueueSize, while restarting > gateway sender with clean queue option > > > Key: GEODE-10277 > URL: https://issues.apache.org/jira/browse/GEODE-10277 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > In case we are checking EventQueueSize in server with full parallel gateway > sender queue, and gateway sender is restarted with --cleanqueue option, > NullPointerException occures in JMX client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10277) Exception thrown when checking gatewaySender EventQueueSize, while restarting gateway sender with clean queue option
[ https://issues.apache.org/jira/browse/GEODE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542345#comment-17542345 ] ASF subversion and git services commented on GEODE-10277: - Commit 0d58250b2336d547d6751e7f3d27f9a8cd432d51 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d58250b23 ] GEODE-10277: For destroyed region don`t check size (#7653) > Exception thrown when checking gatewaySender EventQueueSize, while restarting > gateway sender with clean queue option > > > Key: GEODE-10277 > URL: https://issues.apache.org/jira/browse/GEODE-10277 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > In case we are checking EventQueueSize in server with full parallel gateway > sender queue, and gateway sender is restarted with --cleanqueue option, > NullPointerException occures in JMX client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag reassigned GEODE-10334: --- Assignee: Nabarun Nag > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7016) CI failure: ServerStartupRedundancyRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored FAILED
[
https://issues.apache.org/jira/browse/GEODE-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542340#comment-17542340
]
Geode Integration commented on GEODE-7016:
--
Seen in [windows-acceptance-test-openjdk8
#365|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-acceptance-test-openjdk8/builds/365]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-results/acceptanceTest/1653528413/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-artifacts/1653528413/windows-acceptancetestfiles-openjdk8-1.16.0-build.0250.tgz].
> CI failure: ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
>
>
> Key: GEODE-7016
> URL: https://issues.apache.org/jira/browse/GEODE-7016
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.12.9, 1.13.8, 1.14.4
>Reporter: Anilkumar Gingade
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Attachments: acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (1).tgz,
> acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (2).tgz
>
>
> {noformat}
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.startupReportsOnlineOnlyAfterRedundancyRestored(ServerStartupRedundancyRecoveryNotificationTest.java:142)
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.stopAllMembers(ServerStartupRedundancyRecoveryNotificationTest.java:128)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10311) Intermittent CI failure in AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
[
https://issues.apache.org/jira/browse/GEODE-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542316#comment-17542316
]
Jinmei Liao commented on GEODE-10311:
-
PR available: https://github.com/apache/geode/pull/7709
> Intermittent CI failure in
> AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
> --
>
> Key: GEODE-10311
> URL: https://issues.apache.org/jira/browse/GEODE-10311
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
> Attachments: auth-expiration-artifacts.tgz
>
>
> AuthExpirationBackwardCompatibleDUnitTest >
> registeredInterest_FailedReAuth_non_durableClient fails intermittently. I do
> not know whether this is a test problem or a product problem.
> I first saw the failure in a precheckin test run on JDK17:
> * [https://concourse.apachegeode-ci.info/builds/52805744]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-results/upgradeTest/1652409122/]
> * Test artifacts:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-artifacts/1652409122/upgradetestfiles-geode-pr-7686.tgz]
> The failure also happens on the {{develop}} branch, which does not yet have
> my PR changes. The failure occured 3 times in 100 executions of this test
> method on JDK11 on the {{develop}} branch.
> Stack trace (from my PR precheckin):
> {noformat}
> java.lang.AssertionError:
> Expecting empty but was:
> [CacheClientProxy[identity(heavy-lifter-7d403877-c6e7-5ba6-80ed-0c1ed553c05a(117190:loner):42300:114bc2ba,connection=1;
> port=42332; primary=true; version=GEODE 1.15.0]]
> at
> org.apache.geode.security.AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient(AuthExpirationBackwardCompatibleDUnitTest.java:653)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> 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.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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.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
[jira] [Updated] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10179: - Fix Version/s: 1.12.10 > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542283#comment-17542283 ] ASF subversion and git services commented on GEODE-10179: - Commit c57d8a517636acda776c038029d0c862456684a9 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c57d8a5176 ] Revert "Revert "GEODE-10179: Bump jackson-databind from 2.10.5.1 to 2.12.6.1 (#7506)"" This reverts commit f271b5335c4761b383297be4e7f858492ecd564e. > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10281:
--
Labels: pull-request-available (was: blocks-1.15.0 pull-request-available)
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> {color:#0e101a}It seems that the following PR
> {color}[{color:#4a6ee0}[https://github.com/apache/geode/pull/3044]{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availabi
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10329:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> 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)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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 junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> 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
[jira] [Updated] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10324:
--
Labels: (was: needsTriage)
> [CI Failure] ExportLogsOverHttpDistributedTest >
> testExportWithExactLogLevelFilter
> --
>
> Key: GEODE-10324
> URL: https://issues.apache.org/jira/browse/GEODE-10324
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.16.0
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> > Task :geode-web:distributedTest
> ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter FAILED
> java.lang.AssertionError:
> Expected size: 3 but was: 2 in:
>
> [C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\locator-0,
>
> C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\server-2]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.verifyZipFileContents(ExportLogsDistributedTestBase.java:283)
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.testExportWithExactLogLevelFilter(ExportLogsDistributedTestBase.java:227)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 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.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:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> 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$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
>
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10323:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError:
> expected:<100> but was:<1048576>
>
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10334: -- Labels: pull-request-available (was: needsTriage pull-request-available) > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10332:
--
Labels: (was: needsTriage)
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
[
https://issues.apache.org/jira/browse/GEODE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10333:
--
Labels: (was: needsTriage)
> WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
> geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding
> to heartbeat requests
> --
>
> Key: GEODE-10333
> URL: https://issues.apache.org/jira/browse/GEODE-10333
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
>
> NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
> during geode-wan:upgradeTest which is running tests in parallel. To be
> well-behaved all ports must come from AvailablePortHelper and be well below
> the range of ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk8
> Gradle target: geode-wan:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
> enough info so debugging this test will require a lot of digging through log
> output and studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
> in VM 5, Host Host
> heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
> with 7 VMs, Geode 1.7.0, Java 8
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10331) DistributionImpl.destroyMember keeps cache alive for some number of seconds
[ https://issues.apache.org/jira/browse/GEODE-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10331: -- Labels: blocks-1.16.0 (was: needsTriage) > DistributionImpl.destroyMember keeps cache alive for some number of seconds > --- > > Key: GEODE-10331 > URL: https://issues.apache.org/jira/browse/GEODE-10331 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > org.apache.geode.distributed.internal.DistributionImpl.destroyMember creates > a thread that will hold onto the DIstributesSystem/Cache through the > DirectChannel it has for 3 seconds by default. It could be even longer if > p2p.disconnectDelay is set to a value > 3000. > This can be a problem if the JVM is trying to reconnect since this old cache > uses memory. > Instead of creating a new thread for every call of destroyMember, we should > just have a single ScheduledExecutor that we schedule the background > "closeEndpoint" with. > Also since all this code interacts with the DirectChannel all the logic about > the executor and scheduling it should belong to DirectChannel, not the > DistributionImpl. > When the DirectChannel has disconnect called on it, then it should get rid of > all the tasks scheduled in the executor since they are no longer needed. > I think this issue has been around for a long time because the creation of > the thread refers to fixing "Bug 37944" which is on old bug system that is > not longer used for geode. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
[ https://issues.apache.org/jira/browse/GEODE-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10335: -- Labels: blocks-1.16.0 (was: needsTriage) > TXManagerImpl.close does not remove itself from the static singeton > --- > > Key: GEODE-10335 > URL: https://issues.apache.org/jira/browse/GEODE-10335 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > TXManagerImpl.close does not remove itself from the static singleton. This > causes it to keep the GemFireCacheImpl alive after it has been closed. > The simple fix is to add "currentInstance = null" at the end of the close > method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10337:
--
Labels: blocks-1.16.0 (was: needsTriage)
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Priority: Major
> Labels: blocks-1.16.0
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10336: -- Labels: blocks-1.16.0 (was: needsTriage) > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10285) the auto reconnect after a forced disconnect uses more memory than needed
[ https://issues.apache.org/jira/browse/GEODE-10285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10285: -- Labels: blocks-1.16.0 (was: ) > the auto reconnect after a forced disconnect uses more memory than needed > - > > Key: GEODE-10285 > URL: https://issues.apache.org/jira/browse/GEODE-10285 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: blocks-1.16.0 > > When a member is forced out of the distributed system, if > disable-auto-reconnect=false (the default), then it will attempt to close its > cache, disconnect from the cluster, and then reconnect and create a new > cache. Because of the way this is implemented, the old cache is kept in > memory while the new cache is being created. This can end up causing > reconnect to use much more memory then it needs. That memory will be freed > after the reconnect completes, but it is possible for this to cause the JVM > to run out of memory during the reconnect. > So far I have found two places that keep the old cache around: > 1. InternalDistributedSystem.tryReconnect is passed the old cache as a > parameter. Only one caller exists and only a small block of code in > tryReconnect needs the old cache. So it would be easy to fix this by not > passing it in as a parameter. > 2. InternalDistributedSystem.reconnect (called by tryReconnect) keeps the old > cache in a local variable "cache". It only needs it to initialize "cacheXML" > and "cacheServerCreation". So once those are initialized it would be easy to > drop this ref. But cacheServerCreation also contains references to the old > cache through the "cache" instance variable on CacheServerCreation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10338:
--
Labels: blocks-1.16.0 (was: needsTriage)
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Priority: Major
> Labels: blocks-1.16.0
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7016) CI failure: ServerStartupRedundancyRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored FAILED
[
https://issues.apache.org/jira/browse/GEODE-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542268#comment-17542268
]
Geode Integration commented on GEODE-7016:
--
Seen in [windows-acceptance-test-openjdk8
#364|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-acceptance-test-openjdk8/builds/364]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-results/acceptanceTest/1653514184/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-artifacts/1653514184/windows-acceptancetestfiles-openjdk8-1.16.0-build.0250.tgz].
> CI failure: ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
>
>
> Key: GEODE-7016
> URL: https://issues.apache.org/jira/browse/GEODE-7016
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.12.9, 1.13.8, 1.14.4
>Reporter: Anilkumar Gingade
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Attachments: acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (1).tgz,
> acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (2).tgz
>
>
> {noformat}
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.startupReportsOnlineOnlyAfterRedundancyRestored(ServerStartupRedundancyRecoveryNotificationTest.java:142)
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.stopAllMembers(ServerStartupRedundancyRecoveryNotificationTest.java:128)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7016) CI failure: ServerStartupRedundancyRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored FAILED
[
https://issues.apache.org/jira/browse/GEODE-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542264#comment-17542264
]
Geode Integration commented on GEODE-7016:
--
Seen on support/1.15 in [windows-acceptance-test-openjdk8
#49|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/windows-acceptance-test-openjdk8/builds/49]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1238/test-results/acceptanceTest/1653515371/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1238/test-artifacts/1653515371/windows-acceptancetestfiles-openjdk8-1.15.0-build.1238.tgz].
> CI failure: ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
>
>
> Key: GEODE-7016
> URL: https://issues.apache.org/jira/browse/GEODE-7016
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.12.9, 1.13.8, 1.14.4
>Reporter: Anilkumar Gingade
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Attachments: acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (1).tgz,
> acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (2).tgz
>
>
> {noformat}
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.startupReportsOnlineOnlyAfterRedundancyRestored(ServerStartupRedundancyRecoveryNotificationTest.java:142)
> 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.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.stopAllMembers(ServerStartupRedundancyRecoveryNotificationTest.java:128)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (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:comment-tabpanel=17542263#comment-17542263
]
Geode Integration commented on GEODE-7710:
--
Seen in [distributed-test-openjdk8
#384|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/384]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-results/distributedTest/1653511282/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0250/test-artifacts/1653511282/distributedtestfiles-openjdk8-1.16.0-build.0250.tgz].
> 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, 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.7#820007)
[jira] [Created] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
Darrel Schneider created GEODE-10338:
Summary: LogWriterAppender keeps a InternalDistributedSystem alive
after disconnect
Key: GEODE-10338
URL: https://issues.apache.org/jira/browse/GEODE-10338
Project: Geode
Issue Type: Bug
Components: logging
Reporter: Darrel Schneider
The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
When stopSession is called on the appender, it closes the ManagerLogWriter's
files but does not release its reference to it and the LogWriterAppender
instance is kept around after disconnect. So this ends up keeping the
InternalDistributedSystem alive.
To fix this change LogWriterAppender.stopSession like so:
{code:java}
public synchronized void stopSession() {
LOGGER.info("Stopping session in {}.", this);
if (logWriter == null) {
// we are probably already paused but make sure we are
pause();
return;
}
logWriter.shuttingDown();
pause();
logWriter.closingLogFile();
logWriter = null;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10338:
--
Labels: needsTriage (was: )
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10337:
--
Labels: needsTriage (was: )
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10337) SocketCreatorFactory does not null out instance static
Darrel Schneider created GEODE-10337:
Summary: SocketCreatorFactory does not null out instance static
Key: GEODE-10337
URL: https://issues.apache.org/jira/browse/GEODE-10337
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Darrel Schneider
The SocketCreatorFactory has a static "instance" field that keeps the singleton
factory. The factory has a reference in "distributionConfig" that ends up
keeping the InternalDistributedSystem alive after disconnect.
It also has a static close method but the product never calls it.
To fix this leak do the following:
On InternalDistributedSystem.disconnect add to the end of it:
{code:java}
if (!attemptingToReconnect) {
SocketCreatorFactory.close();
}
{code}
Also I think it would be good to change SocketCreatorFactory.getInstance to
null out the static when close it called like so:
{code:java}
private static synchronized SocketCreatorFactory getInstance(boolean closing)
{
SocketCreatorFactory result = instance;
if (result == null && !closing) {
result = new SocketCreatorFactory();
instance = result;
} else if (result != null && closing) {
instance = null;
}
return result;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
Darrel Schneider created GEODE-10336: Summary: ConnectionTable.close does not null out its static lastInstance field Key: GEODE-10336 URL: https://issues.apache.org/jira/browse/GEODE-10336 Project: Geode Issue Type: Bug Components: membership Reporter: Darrel Schneider The ConnectionTable.close method does a bunch of work but it does not null out the static "lastInstance" atomic. This causes it to keep the ConnectionTable alive which ends up keeping the InternalDistributedSystem alive. The easiest fix is to do this at the end of close: "emergencyClose();". The emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10336: -- Labels: needsTriage (was: ) > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542246#comment-17542246
]
Patrick Johnsn edited comment on GEODE-10312 at 5/25/22 10:10 PM:
--
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.8 to 1.6.1 fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
was (Author: pjohnson):
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.x to 1.5.x fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is
[jira] [Created] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
Darrel Schneider created GEODE-10335: Summary: TXManagerImpl.close does not remove itself from the static singeton Key: GEODE-10335 URL: https://issues.apache.org/jira/browse/GEODE-10335 Project: Geode Issue Type: Bug Components: transactions Reporter: Darrel Schneider TXManagerImpl.close does not remove itself from the static singleton. This causes it to keep the GemFireCacheImpl alive after it has been closed. The simple fix is to add "currentInstance = null" at the end of the close method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
[ https://issues.apache.org/jira/browse/GEODE-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10335: -- Labels: needsTriage (was: ) > TXManagerImpl.close does not remove itself from the static singeton > --- > > Key: GEODE-10335 > URL: https://issues.apache.org/jira/browse/GEODE-10335 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > TXManagerImpl.close does not remove itself from the static singleton. This > causes it to keep the GemFireCacheImpl alive after it has been closed. > The simple fix is to add "currentInstance = null" at the end of the close > method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10321) Acceptance test to exercise Geode's interaction with JDK 17 encapsulation
[ https://issues.apache.org/jira/browse/GEODE-10321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10321: --- Labels: Java17 pull-request-available (was: Java17) > Acceptance test to exercise Geode's interaction with JDK 17 encapsulation > - > > Key: GEODE-10321 > URL: https://issues.apache.org/jira/browse/GEODE-10321 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: Java17, pull-request-available > > Write acceptance tests that demonstrate how to give Geode access to > encapsulated fields in JDK 17 classes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10334: --- Labels: needsTriage pull-request-available (was: needsTriage) > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542246#comment-17542246
]
Patrick Johnsn commented on GEODE-10312:
The `
springdoc.api-docs.path` property should allow the api-docs URL to be changed,
but is being ignored. I just discovered that this works in previous versions of
springdoc, so downgrading from 1.6.x to 1.5.x fixes the issue and everything
works. I'm going to submit a bug against the project and see if we can get this
fixed.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
>
[jira] [Updated] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10334: -- Labels: needsTriage (was: ) > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
Nabarun Nag created GEODE-10334: --- Summary: Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest Key: GEODE-10334 URL: https://issues.apache.org/jira/browse/GEODE-10334 Project: Geode Issue Type: Bug Components: tests Reporter: Nabarun Nag Refactor these tests to remove the deprecated APIs and use the updated test framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availabi
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10329:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> 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)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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 junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> 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
[jira] [Commented] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availa
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542224#comment-17542224
]
Donal Evans commented on GEODE-10329:
-
I was not able to reproduce this failure in 1000 repeat runs using both JDK 11
and JDK 17, but I believe that there is a possible race condition between
beginning shutdown of the GMSHealthMonitor (which stops the executor) and
submitting a task to the executor.
It should be simple to add a check for if the GMSHealthMonitor is shutting down
when encountering the exception and ignoring it if that's the case.
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> 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)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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 junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at
[jira] [Commented] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542177#comment-17542177
]
ASF subversion and git services commented on GEODE-9615:
Commit 431bc151e9d519c0b2d6873fa31e4a58f7ac42eb in geode's branch
refs/heads/support/1.15 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=431bc151e9 ]
GEODE-10327: Overhaul GfshRule to kill processes and save artifacts for
failures (#7571)
PROBLEM
Tests that use GfshRule leave behind orphaned processes and do not save
artifacts for debugging failures.
SOLUTION
GfshRule needs to cleanup all processes it forks. It also needs to save
off all runtime artifacts such as logging, stats, pid files, diskstores
to enable debugging of test failures.
DETAILS
Enhance GfshRule and modify all tests using it for proper debugging and
to prevent test pollution.
Overhaul of GfshRule:
* kill ALL geode processes during cleanup
* use FolderRule to ensure all logs and files are properly saved off
when a test fails
* extract GfshExecutor from JUnit rule code
* GfshExecutor allows a test to use any number of Geode versions with
just one GfshRule
* add Gfsh log level support for easier debugging
* add support for new VmConfiguration to allow control over Geode and
Java versions
* overhaul API of GfshRule and companion classes for better consistency
and design
New FolderRule:
* replaces TemporaryFolder and saves off all content when a test fails
* creates root directory under the gradle worker instead of under temp
Update HTTP session caching module tests:
* use new FolderRule to save all artifacts when a test fails
* use nio Paths for filesystem variables
Update acceptance and upgrade tests that use GfshRule:
* use new improved GfshRule and GfshExecutor
* use new FolderRule instead of TemporaryFolder to save all artifacts
when a test fails
* use --disable-default-server in tests with no clients
* fix flakiness of many tests by using random ports instead of default
or hardcoded port values
* reformat GfshRule API usage in tests to improve readability and
consistency
* add GfshStopper to provide common place to await process stop (stop
locator/server is async so restarting with same ports is very prone
to hitting BindExceptions)
Update ProcessUtils:
* extract NativeProcessUtils and make it public for direct use
* rename InternalProcessUtils as ProcessUtilsProvider and move to its
own class
* rethrow IOExceptions as UncheckedIOExceptions
* fix flakiness in NativeProcessUtilsTest by moving findAvailablePid
into test method
Minor changes:
* improve code formatting and readability
* convert from old io File to nio Path APIs as much as possible
* close output streams to fix filesystem issues on Windows
Fixes flaky test tickets:
* DeployJarAcceptanceTest GEODE-9615
* possibly other tests that uses GfshRule
NOTES
The jdk8, jdk17 and windows labels were used to run tests on more
environments.
This PR contains mostly test and framework changes. The only product
code altered is ServerLauncher and several classes in
org.apache.geode.internal.process, all of which is in geode-core.
(cherry picked from commit 774505e7c74cff8c572be1ec4f4bb2b0f3e1a091)
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost
[jira] [Commented] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542176#comment-17542176 ] ASF subversion and git services commented on GEODE-10327: - Commit 431bc151e9d519c0b2d6873fa31e4a58f7ac42eb in geode's branch refs/heads/support/1.15 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=431bc151e9 ] GEODE-10327: Overhaul GfshRule to kill processes and save artifacts for failures (#7571) PROBLEM Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures. SOLUTION GfshRule needs to cleanup all processes it forks. It also needs to save off all runtime artifacts such as logging, stats, pid files, diskstores to enable debugging of test failures. DETAILS Enhance GfshRule and modify all tests using it for proper debugging and to prevent test pollution. Overhaul of GfshRule: * kill ALL geode processes during cleanup * use FolderRule to ensure all logs and files are properly saved off when a test fails * extract GfshExecutor from JUnit rule code * GfshExecutor allows a test to use any number of Geode versions with just one GfshRule * add Gfsh log level support for easier debugging * add support for new VmConfiguration to allow control over Geode and Java versions * overhaul API of GfshRule and companion classes for better consistency and design New FolderRule: * replaces TemporaryFolder and saves off all content when a test fails * creates root directory under the gradle worker instead of under temp Update HTTP session caching module tests: * use new FolderRule to save all artifacts when a test fails * use nio Paths for filesystem variables Update acceptance and upgrade tests that use GfshRule: * use new improved GfshRule and GfshExecutor * use new FolderRule instead of TemporaryFolder to save all artifacts when a test fails * use --disable-default-server in tests with no clients * fix flakiness of many tests by using random ports instead of default or hardcoded port values * reformat GfshRule API usage in tests to improve readability and consistency * add GfshStopper to provide common place to await process stop (stop locator/server is async so restarting with same ports is very prone to hitting BindExceptions) Update ProcessUtils: * extract NativeProcessUtils and make it public for direct use * rename InternalProcessUtils as ProcessUtilsProvider and move to its own class * rethrow IOExceptions as UncheckedIOExceptions * fix flakiness in NativeProcessUtilsTest by moving findAvailablePid into test method Minor changes: * improve code formatting and readability * convert from old io File to nio Path APIs as much as possible * close output streams to fix filesystem issues on Windows Fixes flaky test tickets: * DeployJarAcceptanceTest GEODE-9615 * possibly other tests that uses GfshRule NOTES The jdk8, jdk17 and windows labels were used to run tests on more environments. This PR contains mostly test and framework changes. The only product code altered is ServerLauncher and several classes in org.apache.geode.internal.process, all of which is in geode-core. (cherry picked from commit 774505e7c74cff8c572be1ec4f4bb2b0f3e1a091) > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, pull-request-available > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes. This range needs to be much
lower.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log output and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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
[jira] [Commented] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542170#comment-17542170 ] ASF subversion and git services commented on GEODE-10327: - Commit 774505e7c74cff8c572be1ec4f4bb2b0f3e1a091 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=774505e7c7 ] GEODE-10327: Overhaul GfshRule to kill processes and save artifacts for failures (#7571) PROBLEM Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures. SOLUTION GfshRule needs to cleanup all processes it forks. It also needs to save off all runtime artifacts such as logging, stats, pid files, diskstores to enable debugging of test failures. DETAILS Enhance GfshRule and modify all tests using it for proper debugging and to prevent test pollution. Overhaul of GfshRule: * kill ALL geode processes during cleanup * use FolderRule to ensure all logs and files are properly saved off when a test fails * extract GfshExecutor from JUnit rule code * GfshExecutor allows a test to use any number of Geode versions with just one GfshRule * add Gfsh log level support for easier debugging * add support for new VmConfiguration to allow control over Geode and Java versions * overhaul API of GfshRule and companion classes for better consistency and design New FolderRule: * replaces TemporaryFolder and saves off all content when a test fails * creates root directory under the gradle worker instead of under temp Update HTTP session caching module tests: * use new FolderRule to save all artifacts when a test fails * use nio Paths for filesystem variables Update acceptance and upgrade tests that use GfshRule: * use new improved GfshRule and GfshExecutor * use new FolderRule instead of TemporaryFolder to save all artifacts when a test fails * use --disable-default-server in tests with no clients * fix flakiness of many tests by using random ports instead of default or hardcoded port values * reformat GfshRule API usage in tests to improve readability and consistency * add GfshStopper to provide common place to await process stop (stop locator/server is async so restarting with same ports is very prone to hitting BindExceptions) Update ProcessUtils: * extract NativeProcessUtils and make it public for direct use * rename InternalProcessUtils as ProcessUtilsProvider and move to its own class * rethrow IOExceptions as UncheckedIOExceptions * fix flakiness in NativeProcessUtilsTest by moving findAvailablePid into test method Minor changes: * improve code formatting and readability * convert from old io File to nio Path APIs as much as possible * close output streams to fix filesystem issues on Windows Fixes flaky test tickets: * DeployJarAcceptanceTest GEODE-9615 * possibly other tests that uses GfshRule NOTES The jdk8, jdk17 and windows labels were used to run tests on more environments. This PR contains mostly test and framework changes. The only product code altered is ServerLauncher and several classes in org.apache.geode.internal.process, all of which is in geode-core. > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, pull-request-available > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542171#comment-17542171
]
ASF subversion and git services commented on GEODE-9615:
Commit 774505e7c74cff8c572be1ec4f4bb2b0f3e1a091 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=774505e7c7 ]
GEODE-10327: Overhaul GfshRule to kill processes and save artifacts for
failures (#7571)
PROBLEM
Tests that use GfshRule leave behind orphaned processes and do not save
artifacts for debugging failures.
SOLUTION
GfshRule needs to cleanup all processes it forks. It also needs to save off all
runtime artifacts such as logging, stats, pid files, diskstores to enable
debugging of test failures.
DETAILS
Enhance GfshRule and modify all tests using it for proper debugging and to
prevent test pollution.
Overhaul of GfshRule:
* kill ALL geode processes during cleanup
* use FolderRule to ensure all logs and files are properly saved off when a
test fails
* extract GfshExecutor from JUnit rule code
* GfshExecutor allows a test to use any number of Geode versions with just one
GfshRule
* add Gfsh log level support for easier debugging
* add support for new VmConfiguration to allow control over Geode and Java
versions
* overhaul API of GfshRule and companion classes for better consistency and
design
New FolderRule:
* replaces TemporaryFolder and saves off all content when a test fails
* creates root directory under the gradle worker instead of under temp
Update HTTP session caching module tests:
* use new FolderRule to save all artifacts when a test fails
* use nio Paths for filesystem variables
Update acceptance and upgrade tests that use GfshRule:
* use new improved GfshRule and GfshExecutor
* use new FolderRule instead of TemporaryFolder to save all artifacts when a
test fails
* use --disable-default-server in tests with no clients
* fix flakiness of many tests by using random ports instead of default or
hardcoded port values
* reformat GfshRule API usage in tests to improve readability and consistency
* add GfshStopper to provide common place to await process stop (stop
locator/server is async so restarting with same ports is very prone to hitting
BindExceptions)
Update ProcessUtils:
* extract NativeProcessUtils and make it public for direct use
* rename InternalProcessUtils as ProcessUtilsProvider and move to its own class
* rethrow IOExceptions as UncheckedIOExceptions
* fix flakiness in NativeProcessUtilsTest by moving findAvailablePid into test
method
Minor changes:
* improve code formatting and readability
* convert from old io File to nio Path APIs as much as possible
* close output streams to fix filesystem issues on Windows
Fixes flaky test tickets:
* DeployJarAcceptanceTest GEODE-9615
* possibly other tests that uses GfshRule
NOTES
The jdk8, jdk17 and windows labels were used to run tests on more environments.
This PR contains mostly test and framework changes. The only product code
altered is ServerLauncher and several classes in
org.apache.geode.internal.process, all of which is in geode-core.
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
>
[jira] [Updated] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
[
https://issues.apache.org/jira/browse/GEODE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10333:
--
Affects Version/s: 1.15.0
1.16.0
> WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
> geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding
> to heartbeat requests
> --
>
> Key: GEODE-10333
> URL: https://issues.apache.org/jira/browse/GEODE-10333
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
> during geode-wan:upgradeTest which is running tests in parallel. To be
> well-behaved all ports must come from AvailablePortHelper and be well below
> the range of ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk8
> Gradle target: geode-wan:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
> enough info so debugging this test will require a lot of digging through log
> output and studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
> in VM 5, Host Host
> heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
> with 7 VMs, Geode 1.7.0, Java 8
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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)
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log output and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Affects Version/s: 1.15.0
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Affects Version/s: 1.16.0
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Updated] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
[
https://issues.apache.org/jira/browse/GEODE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10333:
--
Labels: needsTriage (was: )
> WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
> geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding
> to heartbeat requests
> --
>
> Key: GEODE-10333
> URL: https://issues.apache.org/jira/browse/GEODE-10333
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
> during geode-wan:upgradeTest which is running tests in parallel. To be
> well-behaved all ports must come from AvailablePortHelper and be well below
> the range of ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk8
> Gradle target: geode-wan:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
> enough info so debugging this test will require a lot of digging through log
> output and studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
> in VM 5, Host Host
> heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
> with 7 VMs, Geode 1.7.0, Java 8
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
> 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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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
[jira] [Created] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
Kirk Lund created GEODE-10333:
-
Summary: WANRollingUpgradeNewSenderProcessOldEvent >
bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding to
heartbeat requests
Key: GEODE-10333
URL: https://issues.apache.org/jira/browse/GEODE-10333
Project: Geode
Issue Type: Bug
Components: membership, tests
Reporter: Kirk Lund
NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
during geode-wan:upgradeTest which is running tests in parallel. To be
well-behaved all ports must come from AvailablePortHelper and be well below the
range of ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk8
Gradle target: geode-wan:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes. This range needs to be much
lower.
# The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
enough info so debugging this test will require a lot of digging through log
output and studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
in VM 5, Host Host
heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
with 7 VMs, Geode 1.7.0, Java 8
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
at
org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging of this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging of this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails with SocketTimeoutException after MembershipConfigurationException (was:
ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException)
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Component/s: membership
tests
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails
>
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> 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$execute$0(EngineExecutionOrchestrator.java:54)
> at
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails with SocketTimeoutException (was: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails )
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> ---
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10332:
--
Labels: needsTriage (was: )
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails
>
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 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.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> 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:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> 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$execute$0(EngineExecutionOrchestrator.java:54)
> at
>
[jira] [Created] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails
Kirk Lund created GEODE-10332:
-
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails
Key: GEODE-10332
URL: https://issues.apache.org/jira/browse/GEODE-10332
Project: Geode
Issue Type: Bug
Reporter: Kirk Lund
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
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.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
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:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
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$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
[jira] [Assigned] (GEODE-10305) CI Failure: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest failed
[
https://issues.apache.org/jira/browse/GEODE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen reassigned GEODE-10305:
Assignee: Jianxia Chen
> CI Failure:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> failed
> -
>
> Key: GEODE-10305
> URL: https://issues.apache.org/jira/browse/GEODE-10305
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Assignee: Jianxia Chen
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError: [The Cache Server process
> terminated unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit439159077415808630/server for full details.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/tmp/geode_container_install8549633813411705254/cargo_containers/Tomcat8AndCurrentModules/tomcat-8.5.66/apache-tomcat-8.5.66/lib/slf4j-jdk14-1.7.32.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
> {noformat}
> This is caused by ForcedDisconnectException during cache creation.
> {noformat}
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-e2fd6dd2-c530-54ef-ab7c-b95e0e8cca34(server:240126):41036
> started at Thu May 05 21:36:30 UTC 2022: Member isn't responding to heartbeat
> requests, caused by org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2899)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1183)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5201)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceImpl.(CqServiceImpl.java:166)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceFactoryImpl.create(CqServiceFactoryImpl.java:59)
> at
> org.apache.geode.cache.query.internal.cq.CqServiceProvider.create(CqServiceProvider.java:63)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:1004)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:864)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:913)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:814)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:740)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:259)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl$LifecycleListenerImpl.forcedDisconnect(DistributionImpl.java:941)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1792)
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/331
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10308) CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
[
https://issues.apache.org/jira/browse/GEODE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen reassigned GEODE-10308:
Assignee: Jianxia Chen
> CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
> --
>
> Key: GEODE-10308
> URL: https://issues.apache.org/jira/browse/GEODE-10308
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Eric Shu
>Assignee: Jianxia Chen
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5207)
> at
> org.apache.geode.internal.cache.LocalRegion$Stopper.generateCancelledException(LocalRegion.java:11342)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
> at
> org.apache.geode.internal.cache.execute.InternalFunctionExecutionServiceImpl.onRegion(InternalFunctionExecutionServiceImpl.java:122)
> at
> org.apache.geode.cache.execute.FunctionService.onRegion(FunctionService.java:79)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.getExecutionForFunctionOnRegionWithFilter(ClientServerSessionCache.java:283)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.touchSessions(ClientServerSessionCache.java:101)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager$1.run(DeltaSessionManager.java:534)
> at java.util.TimerThread.mainLoop(Timer.java:556)
> at java.util.TimerThread.run(Timer.java:506)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/334
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542109#comment-17542109
]
Patrick Johnsn edited comment on GEODE-10312 at 5/25/22 4:28 PM:
-
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs. Either way, I'm looking for a
way to avoid changing the URL.
was (Author: pjohnson):
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
>
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542109#comment-17542109
]
Patrick Johnsn commented on GEODE-10312:
That is my concern, but I'm not sure. Most URLs are unchanged, including all
the endpoints I could find mentioned in the docs.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
>
[jira] [Commented] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541884#comment-17541884
]
Juan Ramos commented on GEODE-10312:
{quote}If changing the URL is permissible, then I think this is done, if not, I
will work on finding a way to configure it correctly.
{quote}
I don't think this is permissible as it implies breaking backward
compatibility, doesn't it?.
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
>
[jira] [Updated] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-10155: -- Description: If a Geode client executes a non-HA server function (isHA=false) with a timeout and the function is handled in the Geode server by a "Function Execution Processor" thread (for example by calling the function with onRegion() on a partitioned region without a filter) and the function times-out before the server has answered back with all the results then the ServerConnection thread that originally started to handle the function execution will be stuck forever. If this happens several times and the max-threads parameters is set to a value greater than 0, the server will eventually run out of ServerConnection threads and will not be able to process more client requests. was: If a Geode client executes a server function with a timeout and the function is handled in the Geode server by a "Function Execution Processor" thread (for example by calling the function with onRegion() on a partitioned region without a filter) and the function times-out before the server has answered back with all the results then the ServerConnection thread that originally started to handle the function execution will be stuck forever. If this happens several times and the max-threads parameters is set to a value greater than 0, the server will eventually run out of ServerConnection threads and will not be able to process more client requests. > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a Geode client executes a non-HA server function (isHA=false) with a > timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
