[jira] [Assigned] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal operations
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10383:
---
Assignee: Jinmei Liao
> lucene may log many warnings about BucketNotFound during normal operations
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.16.0
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10380. - Fix Version/s: 1.15.0 Resolution: Fixed > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10380: Affects Version/s: 1.15.0 > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554697#comment-17554697 ] Jinmei Liao commented on GEODE-10380: - PR: https://github.com/apache/geode/pull/7801 > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10380: --- Assignee: Jinmei Liao > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10380: Attachment: Screen Shot 2022-06-14 at 5.37.18 PM.png > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10380: Summary: When dispatcher socket buffer is full, the ReAuth won't get sent to the client causing a deadlock (was: When dispatcher socket buffer is full. the reauth might won't get sent to the client causing a deadlock) > When dispatcher socket buffer is full, the ReAuth won't get sent to the > client causing a deadlock > - > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > Attachments: Screen Shot 2022-06-14 at 5.37.18 PM.png > > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10380) When dispatcher socket buffer is full. the reauth might won't get sent to the client causing a deadlock
Jinmei Liao created GEODE-10380: --- Summary: When dispatcher socket buffer is full. the reauth might won't get sent to the client causing a deadlock Key: GEODE-10380 URL: https://issues.apache.org/jira/browse/GEODE-10380 Project: Geode Issue Type: Bug Components: client/server Reporter: Jinmei Liao # message dispatcher trying to send a reAuth message to the client, but not able to because the socket buffer is full. # client updater is blocked waiting for a regionEntry lock when doing a remove operation. # the regionEntry lock is held by a client operation doing destroy on that same key # the client operation is waiting for the re_auth op to finish. # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10375) REST management discovery endpoint reports incorrect version
[ https://issues.apache.org/jira/browse/GEODE-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10375: --- Assignee: Jinmei Liao (was: Patrick Johnsn) > REST management discovery endpoint reports incorrect version > > > Key: GEODE-10375 > URL: https://issues.apache.org/jira/browse/GEODE-10375 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage, pull-request-available > > prior to GEODE-10312, metadata about the management API url (obtained from > /management) correctly reported /v1/api-docs) > now that we have switched from swagger to springdoc it should now report > /v3/api-docs > see hardcoded value > [here|https://github.com/apache/geode/blob/develop/geode-web-management/src/main/java/org/apache/geode/management/internal/rest/controllers/DocLinksController.java#L38] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10351.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
> Labels: blocks-1.16.0, pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10304.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.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.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
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Assigned] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10324:
---
Assignee: (was: Jinmei Liao)
> [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
>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] [Assigned] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10364:
---
Assignee: Jinmei Liao
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin), tests
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Assignee: Jinmei Liao
>Priority: Minor
> Labels: blocks-1.16.0
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6489) CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551286#comment-17551286
]
Jinmei Liao commented on GEODE-6489:
Test Issue. Gate signaled before 2nd lock is acquired and the the assertion
comes in before the 2nd lock is locked.
> CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
> ---
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.14.0, 1.15.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky, pull-request-available
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546059#comment-17546059
]
Jinmei Liao commented on GEODE-10351:
-
A test issue, not a blocker
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10312.
-
Fix Version/s: 1.15.0
1.16.0
Resolution: 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
> Fix For: 1.15.0, 1.16.0
>
> 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] [Resolved] (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:all-tabpanel
]
Jinmei Liao resolved GEODE-10311.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> 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, pull-request-available
> Fix For: 1.16.0
>
> 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] [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] [Commented] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541644#comment-17541644
]
Jinmei Liao commented on GEODE-10324:
-
Looks like a windows file system issue, transient test issue. Recommend not to
fix.
> [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
> Labels: needsTriage
>
> {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
>
[jira] [Assigned] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10324:
---
Assignee: Jinmei Liao
> [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
> Labels: needsTriage
>
> {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] [Resolved] (GEODE-10314) [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10314.
-
Resolution: Not A Bug
> [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
> --
>
> Key: GEODE-10314
> URL: https://issues.apache.org/jira/browse/GEODE-10314
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.12.10
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxBothTest
> > test[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$60/174734073.run
> in VM 4 running on Host 7b66f9a900ce with 5 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Unable to join the
> distributed system in 67530ms{noformat}
>
> {noformat}
> 384 tests completed, 1 failed, 24 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-results/upgradeTest/1652478284/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-artifacts/1652478284/upgradetestfiles-openjdk8-1.12.10-build.0393.tgz{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10314) [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541217#comment-17541217
]
Jinmei Liao edited comment on GEODE-10314 at 5/23/22 11:45 PM:
---
I believe this is a temporary resource issue, when vm4 is trying to connect to
the cluster, the cluster is having some resource issues and one/more of the
members are not able to exchange heartbeat, so vm4 received a connectivity
exception when trying to start up for the test to continue. The failure has
nothing to do with what the test is trying to test for.
{quote}[vm0] [info 2022/05/13 21:02:57.393 GMT tid=0x124] received suspect message from myself for
172.17.0.6(278):41003: Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:57.411 GMT
tid=0x100] received suspect message from myself for 172.17.0.6(253):41002:
Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:59.111 GMT
tid=0x125] received suspect message from myself for
7b66f9a900ce(106:locator):41000: Member isn't responding to heartbeat
requests
[locator] [info 2022/05/13 21:02:59.064 GMT
tid=0x38] finished waiting for responses to view preparation
[vm1] [warn 2022/05/13 21:02:59.237 GMT tid=0xf6] Statistics
sampling thread detected a wakeup delay of 12657 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[locator] [warn 2022/05/13 21:02:59.204 GMT tid=0x3b] Statistics
sampling thread detected a wakeup delay of 13709 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[vm1] [warn 2022/05/13 21:02:59.918 GMT tid=0xee]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 13,868,839,079 nanoseconds. Period: 2,500,000,000
nanoseconds.
{quote}
was (Author: jinmeiliao):
I believe this is a temporary resource issue, when vm4 is trying to connect to
the cluster, the cluster is having some resource issues and one/more of the
members are not able to exchange heartbeat:
{quote}
[vm0] [info 2022/05/13 21:02:57.393 GMT
tid=0x124] received suspect message from myself for 172.17.0.6(278):41003:
Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:57.411 GMT
tid=0x100] received suspect message from myself for 172.17.0.6(253):41002:
Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:59.111 GMT
tid=0x125] received suspect message from myself for
7b66f9a900ce(106:locator):41000: Member isn't responding to heartbeat
requests
[locator] [info 2022/05/13 21:02:59.064 GMT
tid=0x38] finished waiting for responses to view preparation
[vm1] [warn 2022/05/13 21:02:59.237 GMT tid=0xf6] Statistics
sampling thread detected a wakeup delay of 12657 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[locator] [warn 2022/05/13 21:02:59.204 GMT tid=0x3b] Statistics
sampling thread detected a wakeup delay of 13709 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[vm1] [warn 2022/05/13 21:02:59.918 GMT tid=0xee]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 13,868,839,079 nanoseconds. Period: 2,500,000,000
nanoseconds.
{quote}
> [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
> --
>
> Key: GEODE-10314
> URL: https://issues.apache.org/jira/browse/GEODE-10314
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.12.10
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxBothTest
> > test[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$60/174734073.run
> in VM 4 running on Host 7b66f9a900ce with 5 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Unable to join the
> distributed system in 67530ms{noformat}
>
> {noformat}
> 384 tests completed, 1 failed, 24 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-results/upgradeTest/1652478284/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-artifacts/1652478284/upgradetestfiles-openjdk8-1.12.10-build.0393.tgz{noformat}
>
--
This message was sent by Atlassian Jira
[jira] [Commented] (GEODE-10314) [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17541217#comment-17541217
]
Jinmei Liao commented on GEODE-10314:
-
I believe this is a temporary resource issue, when vm4 is trying to connect to
the cluster, the cluster is having some resource issues and one/more of the
members are not able to exchange heartbeat:
{quote}
[vm0] [info 2022/05/13 21:02:57.393 GMT
tid=0x124] received suspect message from myself for 172.17.0.6(278):41003:
Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:57.411 GMT
tid=0x100] received suspect message from myself for 172.17.0.6(253):41002:
Member isn't responding to heartbeat requests
[vm0] [info 2022/05/13 21:02:59.111 GMT
tid=0x125] received suspect message from myself for
7b66f9a900ce(106:locator):41000: Member isn't responding to heartbeat
requests
[locator] [info 2022/05/13 21:02:59.064 GMT
tid=0x38] finished waiting for responses to view preparation
[vm1] [warn 2022/05/13 21:02:59.237 GMT tid=0xf6] Statistics
sampling thread detected a wakeup delay of 12657 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[locator] [warn 2022/05/13 21:02:59.204 GMT tid=0x3b] Statistics
sampling thread detected a wakeup delay of 13709 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[vm1] [warn 2022/05/13 21:02:59.918 GMT tid=0xee]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 13,868,839,079 nanoseconds. Period: 2,500,000,000
nanoseconds.
{quote}
> [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
> --
>
> Key: GEODE-10314
> URL: https://issues.apache.org/jira/browse/GEODE-10314
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.12.10
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxBothTest
> > test[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$60/174734073.run
> in VM 4 running on Host 7b66f9a900ce with 5 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Unable to join the
> distributed system in 67530ms{noformat}
>
> {noformat}
> 384 tests completed, 1 failed, 24 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-results/upgradeTest/1652478284/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-artifacts/1652478284/upgradetestfiles-openjdk8-1.12.10-build.0393.tgz{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10318.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10314) [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10314:
---
Assignee: Jinmei Liao
> [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
> --
>
> Key: GEODE-10314
> URL: https://issues.apache.org/jira/browse/GEODE-10314
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.12.10
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxBothTest
> > test[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$60/174734073.run
> in VM 4 running on Host 7b66f9a900ce with 5 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Unable to join the
> distributed system in 67530ms{noformat}
>
> {noformat}
> 384 tests completed, 1 failed, 24 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-results/upgradeTest/1652478284/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-artifacts/1652478284/upgradetestfiles-openjdk8-1.12.10-build.0393.tgz{noformat}
>
--
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=17539687#comment-17539687
]
Jinmei Liao commented on GEODE-10311:
-
Ah, thanks! Somehow I thought the line that was failing is trying to assert the
data region is empty, but it's actually the line that asserting the client
proxy session is empty. Will have a fix soon
> 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)
>
[jira] [Commented] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539655#comment-17539655 ] Jinmei Liao commented on GEODE-10287: - Oh, yeah, you are right. The test specifically blocks the operation and cause the `waitForCurrentOperations` to wait forever, that's why the test hang. If we close the distadvisor before the wait, then the wait is a no-op. then the test succeeds. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539627#comment-17539627 ] Jinmei Liao commented on GEODE-10287: - For a closed distAdvisor, the call to the `forceNewMembershipVersion` will do something since it's calling ` operationMonitor.forceNewMembershipVersion();`, the operationMonitor is not closed, so it will increment the ` previousVersionOpCount`, this prevents the `waitForCurrentOperations` to wait if the distAdvisor is not closed. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10115.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10318:
---
Assignee: Jinmei Liao
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539020#comment-17539020
]
Jinmei Liao commented on GEODE-10318:
-
We should not have duplicate entries in the locators attributes. User's
original specification should be honored first. The order of precedence to use
in the locator's list is:
To summarize the thread, the order of precedence is:
# Address from locator list
# hostname-for-client
# bind-address
# guess, prefer hostname
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
Jinmei Liao created GEODE-10318:
---
Summary: locators property is unexpectedly being modified in
InternalLocator
Key: GEODE-10318
URL: https://issues.apache.org/jira/browse/GEODE-10318
Project: Geode
Issue Type: Bug
Components: locator
Reporter: Jinmei Liao
if a locator is started with existing "locators" attributes that points to
itself using ip address, ie.
{code:java}
locators=192.168.0.15[22348]
{code}
if the machine has a hostname specified in its host file
{code:java}
192.168.0.15 abc-a01
{code}
Then after the locator is started, the log banner would show duplicate entries
in the locators attributes:
{code:java}
locators=192.168.0.15[22348],abc-a01[22348]
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10286:
Fix Version/s: 1.15.0
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
>
[jira] [Resolved] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10286.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
>
[jira] [Updated] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10115:
Labels: needsTriage pull-request-available (was: GeodeOperationAPI
pull-request-available)
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10115:
Labels: GeodeOperationAPI pull-request-available (was:
pull-request-available)
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10115:
Affects Version/s: 1.14.4
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
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=17537830#comment-17537830
]
Jinmei Liao commented on GEODE-10311:
-
Is it possible to include the failed run on develop branch?
> 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
>
> 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 org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
[jira] [Assigned] (GEODE-10115) org.apache.geode.security.SecurityManager.init() declaration is inconsistent with method documentation
[
https://issues.apache.org/jira/browse/GEODE-10115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10115:
---
Assignee: Jinmei Liao
> org.apache.geode.security.SecurityManager.init() declaration is inconsistent
> with method documentation
> --
>
> Key: GEODE-10115
> URL: https://issues.apache.org/jira/browse/GEODE-10115
> Project: Geode
> Issue Type: Bug
>Reporter: Lynn Gallinat
>Assignee: Jinmei Liao
>Priority: Major
>
> org.apache.geode.security.SecurityManager.init() does not include a throws
> clause, but the method documentation says it throws
> AuthenticationFailedException.
> {noformat}
> /**
> * Initialize the SecurityManager. This is invoked when a cache is created
> *
> * @param securityProps the security properties obtained using a call to
> *{@link DistributedSystem#getSecurityProperties}
> * @throws AuthenticationFailedException if some exception occurs during the
> initialization
> */
> default void init(Properties securityProps) {}{noformat}
> Either the throws documentation needs to be deleted, or a throws clause needs
> to be added.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (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:all-tabpanel
]
Jinmei Liao reassigned GEODE-10311:
---
Assignee: Jinmei Liao
> 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
>
> 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 org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
>
[jira] [Commented] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537828#comment-17537828
]
Jinmei Liao commented on GEODE-10304:
-
It's a production code flaw, but very unlikely to happen in the production
environment, because it's unlikely that the locator is launched then
immediately forced to stop.
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.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.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
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
>
[jira] [Comment Edited] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537828#comment-17537828
]
Jinmei Liao edited comment on GEODE-10304 at 5/16/22 10:27 PM:
---
It's a production code flaw, but very unlikely to happen in the production
environment, because it's unlikely that the locator is launched then
immediately forced to stop. PR is ready to address this.
was (Author: jinmeiliao):
It's a production code flaw, but very unlikely to happen in the production
environment, because it's unlikely that the locator is launched then
immediately forced to stop.
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.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.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
>
[jira] [Assigned] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10304:
---
Assignee: Jinmei Liao
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.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.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
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Comment Edited] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536337#comment-17536337 ] Jinmei Liao edited comment on GEODE-10287 at 5/12/22 8:46 PM: -- If I close the distAdvisor after "waitForCurrentOperations()", the ConnectionCloseSSLTLSDUnitTest.connectionWithHungReaderIsCloseableAndUnhangsReader() will hang, that test will block the current operation, and make sure cache is still closable. If we waitForCurrentOperations before we close the distAdvisor, it will wait forever. Recommend not to fix this for now and wait till I discuss more with [~dschneider] who filed this ticket. was (Author: jinmeiliao): If I close the distAdvisor after "waitForCurrentOperations()", the ConnectionCloseSSLTLSDUnitTest.connectionWithHungReaderIsCloseableAndUnhangsReader() will hang, that test will block the current operation, and make sure cache is still closable. If we waitForCurrentOperations before we close the distAdvisor, it will wait forever. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17536337#comment-17536337 ] Jinmei Liao commented on GEODE-10287: - If I close the distAdvisor after "waitForCurrentOperations()", the ConnectionCloseSSLTLSDUnitTest.connectionWithHungReaderIsCloseableAndUnhangsReader() will hang, that test will block the current operation, and make sure cache is still closable. If we waitForCurrentOperations before we close the distAdvisor, it will wait forever. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10287: --- Assignee: Jinmei Liao (was: Jianxia Chen) > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10271) CI failure: dead server monitor fails to increment server count after a new server is started
[
https://issues.apache.org/jira/browse/GEODE-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10271:
Fix Version/s: 1.16.0
> CI failure: dead server monitor fails to increment server count after a new
> server is started
> -
>
> Key: GEODE-10271
> URL: https://issues.apache.org/jira/browse/GEODE-10271
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14919517]
>
> {noformat}
> > Task :geode-core:integrationTest
> ConnectionProxyJUnitTest > testDeadServerMonitorPingNature1 FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest
> expected:<1> but was:<0> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest.testDeadServerMonitorPingNature1(ConnectionProxyJUnitTest.java:246)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<0>
> 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.cache.tier.sockets.ConnectionProxyJUnitTest.lambda$testDeadServerMonitorPingNature1$0(ConnectionProxyJUnitTest.java:247)
> 4053 tests completed, 1 failed, 84 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-results/integrationTest/1651501470/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-artifacts/1651501470/integrationtestfiles-openjdk8-1.15.0-build.1131.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10271) CI failure: dead server monitor fails to increment server count after a new server is started
[
https://issues.apache.org/jira/browse/GEODE-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10271.
-
Resolution: Fixed
Cleaned up the test and hopefully it will eliminate this issue.
> CI failure: dead server monitor fails to increment server count after a new
> server is started
> -
>
> Key: GEODE-10271
> URL: https://issues.apache.org/jira/browse/GEODE-10271
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14919517]
>
> {noformat}
> > Task :geode-core:integrationTest
> ConnectionProxyJUnitTest > testDeadServerMonitorPingNature1 FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest
> expected:<1> but was:<0> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest.testDeadServerMonitorPingNature1(ConnectionProxyJUnitTest.java:246)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<0>
> 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.cache.tier.sockets.ConnectionProxyJUnitTest.lambda$testDeadServerMonitorPingNature1$0(ConnectionProxyJUnitTest.java:247)
> 4053 tests completed, 1 failed, 84 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-results/integrationTest/1651501470/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-artifacts/1651501470/integrationtestfiles-openjdk8-1.15.0-build.1131.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10287: --- Assignee: Jinmei Liao > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10286:
---
Assignee: Jinmei Liao
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
>
[jira] [Updated] (GEODE-9390) DistributedSystem nodes is counted twice on each server member
[
https://issues.apache.org/jira/browse/GEODE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9390:
---
Fix Version/s: 1.15.0
> DistributedSystem nodes is counted twice on each server member
> --
>
> Key: GEODE-9390
> URL: https://issues.apache.org/jira/browse/GEODE-9390
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barrett Oglesby
>Assignee: Matthew Reddington
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Once in ClusterDistributionManager.startThreads:
> {noformat}
> [warn 2021/06/20 16:20:16.152 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.153 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=1
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.startThreads(ClusterDistributionManager.java:691)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:504)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
> And once in ClusterDistributionManager.create:
> {noformat}
> [warn 2021/06/20 16:20:16.155 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.156 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=2
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9390) DistributedSystem nodes is counted twice on each server member
[
https://issues.apache.org/jira/browse/GEODE-9390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9390.
Assignee: Matthew Reddington
Resolution: Fixed
> DistributedSystem nodes is counted twice on each server member
> --
>
> Key: GEODE-9390
> URL: https://issues.apache.org/jira/browse/GEODE-9390
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barrett Oglesby
>Assignee: Matthew Reddington
>Priority: Major
> Labels: pull-request-available
>
> Once in ClusterDistributionManager.startThreads:
> {noformat}
> [warn 2021/06/20 16:20:16.152 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.153 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=1
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.startThreads(ClusterDistributionManager.java:691)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:504)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
> And once in ClusterDistributionManager.create:
> {noformat}
> [warn 2021/06/20 16:20:16.155 HST server-1 tid=0x1]
> ClusterDistributionManager.handleManagerStartup
> id=192.168.1.8(server-1:58386):41001; kind=10
> [warn 2021/06/20 16:20:16.156 HST server-1 tid=0x1]
> DistributionStats.incNodes nodes=2
> java.lang.Exception
> at
> org.apache.geode.distributed.internal.DistributionStats.incNodes(DistributionStats.java:1362)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleManagerStartup(ClusterDistributionManager.java:1809)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.addNewMember(ClusterDistributionManager.java:1062)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:780)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10271) CI failure: dead server monitor fails to increment server count after a new server is started
[
https://issues.apache.org/jira/browse/GEODE-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-10271:
---
Assignee: Jinmei Liao
> CI failure: dead server monitor fails to increment server count after a new
> server is started
> -
>
> Key: GEODE-10271
> URL: https://issues.apache.org/jira/browse/GEODE-10271
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14919517]
>
> {noformat}
> > Task :geode-core:integrationTest
> ConnectionProxyJUnitTest > testDeadServerMonitorPingNature1 FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest
> expected:<1> but was:<0> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.ConnectionProxyJUnitTest.testDeadServerMonitorPingNature1(ConnectionProxyJUnitTest.java:246)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<0>
> 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.cache.tier.sockets.ConnectionProxyJUnitTest.lambda$testDeadServerMonitorPingNature1$0(ConnectionProxyJUnitTest.java:247)
> 4053 tests completed, 1 failed, 84 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-results/integrationTest/1651501470/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1131/test-artifacts/1651501470/integrationtestfiles-openjdk8-1.15.0-build.1131.tgz{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10260. - Fix Version/s: 1.15.0 Resolution: Fixed > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10260: --- Assignee: Jinmei Liao > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
Jinmei Liao created GEODE-10260: --- Summary: FilterProfile of a peer server would sometimes miss a CQ when server initializes Key: GEODE-10260 URL: https://issues.apache.org/jira/browse/GEODE-10260 Project: Geode Issue Type: Bug Reporter: Jinmei Liao When server2 initializes at the same time as client register CQ while connected to server1, when below sequence happened, server2 will have a wrong idea what cq server1 should serve: 1. server2 creates the partitioned region and sends a CreateRegionMessage to server1 2. server1 process this message and adds server2 to its profile list 3. server1 reply to server2 with a CreateRegionReplyMessage 4. At thee same time server1 does register cq locally and send a REGISTER_CQ message to server2 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache profile yet, so it wants to save the message to the "to_be_processed" queue, but get stuck there. 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now has server1's cache profile, processed the message and then processed everything in the "to_be_processed" queue. 7. Now #5 gets unstuck and continues, adds the message to the queue, but the queue is never processed again, so now in server2's viewpoint, server1 is not serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reopened GEODE-10106:
-
This happened on last weekend's regression runs as well. This stack trace
showed up in the logs:
{quote}
system.log contains java.lang.NullPointerException
at
org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:866)
at
org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1466)
at
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{quote}
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
>
[jira] [Resolved] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10243.
-
Fix Version/s: 1.15.0
Assignee: Jinmei Liao (was: Dan Smith)
Resolution: Fixed
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10097. - Resolution: Fixed > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-10144: - I am going to revert the revert, so reopening this ticket again: the exception happened on the old client connecting to the new server. Once CQ determined this user is expired, it will wait for 5 seconds for the client to do some operation to refresh the subject, but the implementation of the security manager only throws the AuthExpiredException every 30 seconds, so the client operation never gets that exception therefore the refresh didn't happen. CQ disconnects the client, but the client didn't know that and continues operations, thus it receives this exception. The correct behavior is security manager once determines a user expired, it should throw the auth-expired exception all the time, then if the client choose to send in a refreshed token, then CQ will continue, if the client didn't send in a refreshed token, then client should get AuthenticationFailedException immediately after the 2nd try. > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-10097: - the commit was reverted due to some test failures > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17510939#comment-17510939 ] Jinmei Liao commented on GEODE-10144: - commit reverted > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10144. - Fix Version/s: 1.15.0 Resolution: Fixed > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Jinmei Liao >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10092. - Fix Version/s: 1.15.0 Resolution: Fixed > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9451) On demand authentication expiration and re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9451. Resolution: Fixed > On demand authentication expiration and re-authentication > - > > Key: GEODE-9451 > URL: https://issues.apache.org/jira/browse/GEODE-9451 > Project: Geode > Issue Type: New Feature > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > This is to implement the feature proposed in this RFC > https://cwiki.apache.org/confluence/display/GEODE/On+Demand+Geode+Authentication+Expiration+and+Re-authentication -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10097. - Fix Version/s: 1.15.0 1.16.0 Assignee: Jinmei Liao Resolution: Fixed > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503802#comment-17503802 ] Jinmei Liao edited comment on GEODE-10092 at 3/9/22, 7:43 PM: -- The test that failed with the invalid region size log is: RenameDunitTest.givenCrashDuringRename_thenDoesNotLeaveInconsistencies, Note in this test, the negative region size is reported on a server, but the the original ticket is on the client, so this may not be the same code path that caused this problem. was (Author: jinmeiliao): The test that failed with the invalid region size log is: RenameDunitTest.givenCrashDuringRename_thenDoesNotLeaveInconsistencies, > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503802#comment-17503802 ] Jinmei Liao edited comment on GEODE-10092 at 3/9/22, 7:42 PM: -- The test that failed with the invalid region size log is: RenameDunitTest.givenCrashDuringRename_thenDoesNotLeaveInconsistencies, was (Author: jinmeiliao): The test that failed with the invalid region size report is: RenameDunitTest.givenCrashDuringRename_thenDoesNotLeaveInconsistencies, > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503802#comment-17503802 ] Jinmei Liao commented on GEODE-10092: - The test that failed with the invalid region size report is: RenameDunitTest.givenCrashDuringRename_thenDoesNotLeaveInconsistencies, > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10097: Labels: GeodeOperationAPI (was: ) > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
Jinmei Liao created GEODE-10097: --- Summary: Do not use Thread.sleep in MessageDispatcher for re-authentication feature Key: GEODE-10097 URL: https://issues.apache.org/jira/browse/GEODE-10097 Project: Geode Issue Type: Improvement Components: client queues, client/server Reporter: Jinmei Liao MessageDispatcher uses Thread.sleep and wakes up intervals to recheck authorization to see if new subject has re-logged in or not, if not, it will call "authorize" again and again till timeout. Suggest using "wait/notify" mechanism to wait for the subject to be updated, this way we don't use Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
[ https://issues.apache.org/jira/browse/GEODE-10092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17499150#comment-17499150 ] Jinmei Liao commented on GEODE-10092: - This exception is hard to reproduce. EntriesSet.size() ultimately calls LocalRegion.getRegionSize(), first step is to add logging message when size goes negative for further investigation when this error happens. > IllegalArgumentException: Illegal Capacity (with a negative value) thrown > from EntriesSet.toArray() in client > - > > Key: GEODE-10092 > URL: https://issues.apache.org/jira/browse/GEODE-10092 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > > In some case, we see the following stack trace when executing > entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: > Illegal Capacity: -40 > at java.util.ArrayList.(ArrayList.java:157) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) > at > org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) > looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10092) IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client
Jinmei Liao created GEODE-10092: --- Summary: IllegalArgumentException: Illegal Capacity (with a negative value) thrown from EntriesSet.toArray() in client Key: GEODE-10092 URL: https://issues.apache.org/jira/browse/GEODE-10092 Project: Geode Issue Type: Bug Reporter: Jinmei Liao In some case, we see the following stack trace when executing entriesSet.toArray() call: Exception java.lang.IllegalArgumentException: Illegal Capacity: -40 at java.util.ArrayList.(ArrayList.java:157) at org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:251) at org.apache.geode.internal.cache.EntriesSet.toArray(EntriesSet.java:245) looks like the entriesSet.size() call will sometimes returns a negative value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10084) Gfsh ImportDataCommand causes a ClassCastException
[ https://issues.apache.org/jira/browse/GEODE-10084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10084. - Fix Version/s: 1.15.0 1.16.0 Assignee: Jinmei Liao Resolution: Fixed > Gfsh ImportDataCommand causes a ClassCastException > -- > > Key: GEODE-10084 > URL: https://issues.apache.org/jira/browse/GEODE-10084 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > When `ImportDataFunction` throws an InternalGemfireError, gfsh will report a > `ClassCastException` > error 2022/02/22 09:55:27.275 CST ech-10-157-129-162-locator1 Connection(10)-10.157.129.162> tid=0x84] Could not execute “import data > --region=UDTVersionIndex_Stage > --file=/apps_data_01/fraud/UDTVersionIndex_Stage.gfd > --member=ech-10-157-129-162-server1”. > java.lang.ClassCastException: org.apache.geode.InternalGemFireError cannot be > cast to org.apache.geode.management.internal.functions.CliFunctionResult > at > org.apache.geode.management.internal.cli.result.model.ResultModel.addTableAndSetStatus(ResultModel.java:214) > at > org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:377) > at > org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:357) > at > org.apache.geode.management.internal.cli.commands.ImportDataCommand.importData(ImportDataCommand.java:74) > 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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:138) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:148) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:76) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:61) > at > org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:132) > at > org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommandReturningJson(OnlineCommandProcessor.java:138) > at > org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1252) > at > org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:424) > 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at > com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) > at > com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) > at > com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) > at > com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) > at > com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) > at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) > at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) > at >
[jira] [Created] (GEODE-10084) Gfsh ImportDataCommand causes a ClassCastException
Jinmei Liao created GEODE-10084: --- Summary: Gfsh ImportDataCommand causes a ClassCastException Key: GEODE-10084 URL: https://issues.apache.org/jira/browse/GEODE-10084 Project: Geode Issue Type: Bug Components: gfsh Reporter: Jinmei Liao When `ImportDataFunction` throws an InternalGemfireError, gfsh will report a `ClassCastException` error 2022/02/22 09:55:27.275 CST ech-10-157-129-162-locator1 tid=0x84] Could not execute “import data --region=UDTVersionIndex_Stage --file=/apps_data_01/fraud/UDTVersionIndex_Stage.gfd --member=ech-10-157-129-162-server1”. java.lang.ClassCastException: org.apache.geode.InternalGemFireError cannot be cast to org.apache.geode.management.internal.functions.CliFunctionResult at org.apache.geode.management.internal.cli.result.model.ResultModel.addTableAndSetStatus(ResultModel.java:214) at org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:377) at org.apache.geode.management.internal.cli.result.model.ResultModel.createMemberStatusResult(ResultModel.java:357) at org.apache.geode.management.internal.cli.commands.ImportDataCommand.importData(ImportDataCommand.java:74) 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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:282) at org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:138) at org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:148) at org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:76) at org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:61) at org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:132) at org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommandReturningJson(OnlineCommandProcessor.java:138) at org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1252) at org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:424) 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 sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193) at com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117) at com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54) at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237) at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829) at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] [Resolved] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-10042. - Fix Version/s: 1.15.0 Resolution: Fixed > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10042: Affects Version/s: 1.14.3 > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.3 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
[ https://issues.apache.org/jira/browse/GEODE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10042: --- Assignee: Jinmei Liao > ServerConnection would make the ClientUserAuths null when there are still > client using that connection > -- > > Key: GEODE-10042 > URL: https://issues.apache.org/jira/browse/GEODE-10042 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > In `handleTermination` method, when we calculate there are still client > threads using this connection, we should not cleanup clientUserAuth (this is > done correctly), but we make the clientUserAuth null regardless, this would > result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10042) ServerConnection would make the ClientUserAuths null when there are still client using that connection
Jinmei Liao created GEODE-10042: --- Summary: ServerConnection would make the ClientUserAuths null when there are still client using that connection Key: GEODE-10042 URL: https://issues.apache.org/jira/browse/GEODE-10042 Project: Geode Issue Type: Bug Components: client/server Reporter: Jinmei Liao In `handleTermination` method, when we calculate there are still client threads using this connection, we should not cleanup clientUserAuth (this is done correctly), but we make the clientUserAuth null regardless, this would result in NPE sent down to the client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-10022:
Fix Version/s: 1.15.0
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
[
https://issues.apache.org/jira/browse/GEODE-10022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10022.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CacheClientProxy will omit exception stack trace when handling an exception
> ---
>
> Key: GEODE-10022
> URL: https://issues.apache.org/jira/browse/GEODE-10022
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.3
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> line 807 in CacheClientProxy:
> {quote}
> } catch (Exception ex) {
> if (_cache.getSecurityLogger().warningEnabled()) {
> _cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
> }
> }
> {quote}
> this will cause the exception to not to be fully logged to see the cause of
> it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10022) CacheClientProxy will omit exception stack trace when handling an exception
Jinmei Liao created GEODE-10022:
---
Summary: CacheClientProxy will omit exception stack trace when
handling an exception
Key: GEODE-10022
URL: https://issues.apache.org/jira/browse/GEODE-10022
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.14.3
Reporter: Jinmei Liao
line 807 in CacheClientProxy:
{quote}
} catch (Exception ex) {
if (_cache.getSecurityLogger().warningEnabled()) {
_cache.getSecurityLogger().warning(String.format("%s : %s", this, ex));
}
}
{quote}
this will cause the exception to not to be fully logged to see the cause of it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9985) Mass-Test-Run: SlowDispatcherDUnitTest > registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
[
https://issues.apache.org/jira/browse/GEODE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9985.
Fix Version/s: 1.16.0
Resolution: Fixed
> Mass-Test-Run: SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> --
>
> Key: GEODE-9985
> URL: https://issues.apache.org/jira/browse/GEODE-9985
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.16.0
>
>
> {code:java}
> SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest$$Lambda$299/1561169457.run
> in VM 3 running on Host
> heavy-lifter-f18312bf-ecf3-5384-8b36-e5d91bf8ebb9.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.registeredInterest_durableClient_kill_primarySever_receives_marker(SlowDispatcherDUnitTest.java:135)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest
> expected: 49
> but was: 40 within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$registeredInterest_durableClient_kill_primarySever_receives_marker$bb17a952$2(SlowDispatcherDUnitTest.java:137)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: 49
> but was: 40
> at
> sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$null$2(SlowDispatcherDUnitTest.java:137)
> 8357 tests completed, 1 failed, 414 skipped
> {code}
> Test report artifacts from {color:#172b4d}this{color} job are available at:
> http:{color:#172b4d}//files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642831372/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9985) Mass-Test-Run: SlowDispatcherDUnitTest > registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
[
https://issues.apache.org/jira/browse/GEODE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-9985:
--
Assignee: Jinmei Liao
> Mass-Test-Run: SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> --
>
> Key: GEODE-9985
> URL: https://issues.apache.org/jira/browse/GEODE-9985
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {code:java}
> SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest$$Lambda$299/1561169457.run
> in VM 3 running on Host
> heavy-lifter-f18312bf-ecf3-5384-8b36-e5d91bf8ebb9.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.registeredInterest_durableClient_kill_primarySever_receives_marker(SlowDispatcherDUnitTest.java:135)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest
> expected: 49
> but was: 40 within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$registeredInterest_durableClient_kill_primarySever_receives_marker$bb17a952$2(SlowDispatcherDUnitTest.java:137)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: 49
> but was: 40
> at
> sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$null$2(SlowDispatcherDUnitTest.java:137)
> 8357 tests completed, 1 failed, 414 skipped
> {code}
> Test report artifacts from {color:#172b4d}this{color} job are available at:
> http:{color:#172b4d}//files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642831372/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9996) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
[
https://issues.apache.org/jira/browse/GEODE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9996.
Assignee: Jinmei Liao
Resolution: Not A Problem
> CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> --
>
> Key: GEODE-9996
> URL: https://issues.apache.org/jira/browse/GEODE-9996
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> Test failed with the following exception:
> {code:java}
> SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> FAILED
> java.lang.AssertionError: expected:<0> but was:<5>
> 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.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:170)
> {code}
> hydraDB results: https://hydradb.hdb.gemfire-ci.info/hdb/testresult/13209951
> test artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0004/test-artifacts/1643254840/acceptancetestfiles-openjdk8-1.16.0-build.0004.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9996) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
[
https://issues.apache.org/jira/browse/GEODE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9996:
---
Labels: (was: needsTriage)
> CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> --
>
> Key: GEODE-9996
> URL: https://issues.apache.org/jira/browse/GEODE-9996
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
>
> Test failed with the following exception:
> {code:java}
> SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
> FAILED
> java.lang.AssertionError: expected:<0> but was:<5>
> 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.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:170)
> {code}
> hydraDB results: https://hydradb.hdb.gemfire-ci.info/hdb/testresult/13209951
> test artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0004/test-artifacts/1643254840/acceptancetestfiles-openjdk8-1.16.0-build.0004.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9996) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersReachTheRightReceivers
[
https://issues.apache.org/jira/browse/GEODE-9996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484913#comment-17484913
]
Jinmei Liao commented on GEODE-9996:
Looks like the `haproxy` services started on the docker container are not
running properly in this run. The server/locators in the local site has trouble
connecting to these services:
{quote}
[vm1] [warn 2022/01/27 00:55:20.464 UTC tid=0x41] Could not connect to: 172.18.0.4:2324
[vm1] java.io.EOFException
[vm1] at java.io.DataInputStream.readByte(DataInputStream.java:267)
[vm1] at
org.apache.geode.cache.client.internal.ClientSideHandshakeImpl.handshakeWithServer(ClientSideHandshakeImpl.java:193)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:107)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:119)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:236)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
[vm1] at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
[vm1] at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
[vm1] at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
[vm1] at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
[vm1] at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
[vm1] at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1081)
[vm1] [warn 2022/01/27 00:55:20.464 UTC tid=0x43] Could not connect to: 172.18.0.4:2324
[vm1] java.io.EOFException
[vm1] at java.io.DataInputStream.readByte(DataInputStream.java:267)
[vm1] at
org.apache.geode.cache.client.internal.ClientSideHandshakeImpl.handshakeWithServer(ClientSideHandshakeImpl.java:193)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:107)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:119)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:236)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
[vm1] at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
[vm1] at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
[vm1] at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
[vm1] at
org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
[vm1] at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
[vm1] at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
[vm1] at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1081)
[vm1] [warn 2022/01/27 00:55:20.464 UTC tid=0x47] Could not connect to: 172.18.0.4:2324
[vm1] java.io.EOFException
[vm1] at java.io.DataInputStream.readByte(DataInputStream.java:267)
[vm1] at
org.apache.geode.cache.client.internal.ClientSideHandshakeImpl.handshakeWithServer(ClientSideHandshakeImpl.java:193)
[vm1] at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:107)
[vm1] at
[jira] [Updated] (GEODE-9739) CI: WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo failed with MemberDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9739:
---
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> CI: WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo failed
> with MemberDisconnectedException
> --
>
> Key: GEODE-9739
> URL: https://issues.apache.org/jira/browse/GEODE-9739
> Project: Geode
> Issue Type: Bug
> Components: membership, wan
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Hale Bales
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo >
> CreateGatewaySenderMixedSiteOneCurrentSiteTwo[from_v1.12.2] 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-vm6.log' at line 481[fatal
> 2021/10/13 23:34:55.115 UTC receiver,heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3-37210> tid=830]
> Membership service failure: Membership coordinator
> heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(39325:locator):53919
> has declared that a network partition has occurred
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Membership coordinator
> heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(39325:locator):53919
> has declared that a network partition has occurred
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processNetworkPartitionMessage(GMSJoinLeave.java:1466)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.base/java.lang.Thread.run(Thread.java:829)
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 549[fatal
> 2021/10/13 23:34:54.989 UTC tid=858] Possible
> loss of quorum due to the loss of 1 cache processes:
> [heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(41092):53920]
> ---
> Found suspect string in 'dunit_suspect-vm4.log' at line 551[fatal
> 2021/10/13 23:34:56.179 UTC tid=858]
> Membership service failure: Exiting due to possible network partition event
> due to loss of 1 cache processes:
> [heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(41092):53920]
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Exiting due to possible network partition event due to loss of 1 cache
> processes:
> [heavy-lifter-f2dde05e-a413-5672-b192-2396306457b3(41092):53920]
> at
>
[jira] [Commented] (GEODE-9985) Mass-Test-Run: SlowDispatcherDUnitTest > registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
[
https://issues.apache.org/jira/browse/GEODE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482052#comment-17482052
]
Jinmei Liao commented on GEODE-9985:
This is a test issue. Primary server is killed before all the put operations
are done.
> Mass-Test-Run: SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> --
>
> Key: GEODE-9985
> URL: https://issues.apache.org/jira/browse/GEODE-9985
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: GeodeOperationAPI
>
> {code:java}
> SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest$$Lambda$299/1561169457.run
> in VM 3 running on Host
> heavy-lifter-f18312bf-ecf3-5384-8b36-e5d91bf8ebb9.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.registeredInterest_durableClient_kill_primarySever_receives_marker(SlowDispatcherDUnitTest.java:135)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest
> expected: 49
> but was: 40 within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$registeredInterest_durableClient_kill_primarySever_receives_marker$bb17a952$2(SlowDispatcherDUnitTest.java:137)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: 49
> but was: 40
> at
> sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$null$2(SlowDispatcherDUnitTest.java:137)
> 8357 tests completed, 1 failed, 414 skipped
> {code}
> Test report artifacts from {color:#172b4d}this{color} job are available at:
> http:{color:#172b4d}//files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642831372/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9985) Mass-Test-Run: SlowDispatcherDUnitTest > registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
[
https://issues.apache.org/jira/browse/GEODE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9985:
---
Labels: GeodeOperationAPI (was: needsTriage)
> Mass-Test-Run: SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> --
>
> Key: GEODE-9985
> URL: https://issues.apache.org/jira/browse/GEODE-9985
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
> Labels: GeodeOperationAPI
>
> {code:java}
> SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest$$Lambda$299/1561169457.run
> in VM 3 running on Host
> heavy-lifter-f18312bf-ecf3-5384-8b36-e5d91bf8ebb9.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.registeredInterest_durableClient_kill_primarySever_receives_marker(SlowDispatcherDUnitTest.java:135)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest
> expected: 49
> but was: 40 within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$registeredInterest_durableClient_kill_primarySever_receives_marker$bb17a952$2(SlowDispatcherDUnitTest.java:137)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: 49
> but was: 40
> at
> sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$null$2(SlowDispatcherDUnitTest.java:137)
> 8357 tests completed, 1 failed, 414 skipped
> {code}
> Test report artifacts from {color:#172b4d}this{color} job are available at:
> http:{color:#172b4d}//files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642831372/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9857.
Resolution: Not A Problem
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480239#comment-17480239
]
Jinmei Liao commented on GEODE-9857:
the test failed at waiting for the locator to come up. The test hasn't failed
since, so must be a resource issue. Close this for now. Feel free to reopen if
it happens again.
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9935) CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
[
https://issues.apache.org/jira/browse/GEODE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9935.
Fix Version/s: 1.15.0
Resolution: Not A Problem
> CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
> --
>
> Key: GEODE-9935
> URL: https://issues.apache.org/jira/browse/GEODE-9935
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
> Fix For: 1.15.0
>
>
> CI Failure in upgrade tests in RollingUpgradeWithGfshDUnitTest >
> testRollingUpgradeWithDeployment. starting locator exits with status of 1,
> not the expected 0.
> {code:java}
> > Task :geode-assembly:upgradeTest
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.10.0]
> FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e35c359d41713de9: gfsh -e start locator --name=loc2 --port=24585
> --http-service-port=0 --locators=localhost[24583]
> --J=-Dgemfire.jmx-manager-port=24586]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:107)
> 134 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-results/upgradeTest/1641589807/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-artifacts/1641589807/upgradetestfiles-openjdk8-1.15.0-build.0767.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9935) CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
[
https://issues.apache.org/jira/browse/GEODE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478937#comment-17478937
]
Jinmei Liao commented on GEODE-9935:
I believe this is temporary resource issue, when starting the locator, there
are 25 seconds gap in the logs:
[info 2022/01/07 20:06:05.134 UTC loc2 tid=0x1]
ClusterManagementServiceInfoRequestHandler installed
[warn 2022/01/07 20:06:30.111 UTC loc2 tid=0x40] Statistics
sampling thread detected a wakeup delay of 17478 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[warn 2022/01/07 20:06:30.184 UTC loc2 tid=0x31]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 20,621,115,279 nanoseconds. Period: 2,500,000,000
nanoseconds.
Closing this ticket for now.
> CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
> --
>
> Key: GEODE-9935
> URL: https://issues.apache.org/jira/browse/GEODE-9935
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> CI Failure in upgrade tests in RollingUpgradeWithGfshDUnitTest >
> testRollingUpgradeWithDeployment. starting locator exits with status of 1,
> not the expected 0.
> {code:java}
> > Task :geode-assembly:upgradeTest
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.10.0]
> FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e35c359d41713de9: gfsh -e start locator --name=loc2 --port=24585
> --http-service-port=0 --locators=localhost[24583]
> --J=-Dgemfire.jmx-manager-port=24586]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:107)
> 134 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-results/upgradeTest/1641589807/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-artifacts/1641589807/upgradetestfiles-openjdk8-1.15.0-build.0767.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9935) CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
[
https://issues.apache.org/jira/browse/GEODE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reassigned GEODE-9935:
--
Assignee: Jinmei Liao
> CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
> --
>
> Key: GEODE-9935
> URL: https://issues.apache.org/jira/browse/GEODE-9935
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> CI Failure in upgrade tests in RollingUpgradeWithGfshDUnitTest >
> testRollingUpgradeWithDeployment. starting locator exits with status of 1,
> not the expected 0.
> {code:java}
> > Task :geode-assembly:upgradeTest
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.10.0]
> FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e35c359d41713de9: gfsh -e start locator --name=loc2 --port=24585
> --http-service-port=0 --locators=localhost[24583]
> --J=-Dgemfire.jmx-manager-port=24586]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:107)
> 134 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-results/upgradeTest/1641589807/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-artifacts/1641589807/upgradetestfiles-openjdk8-1.15.0-build.0767.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9935) CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
[
https://issues.apache.org/jira/browse/GEODE-9935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-9935:
---
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> CI Failure: RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment
> --
>
> Key: GEODE-9935
> URL: https://issues.apache.org/jira/browse/GEODE-9935
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> CI Failure in upgrade tests in RollingUpgradeWithGfshDUnitTest >
> testRollingUpgradeWithDeployment. starting locator exits with status of 1,
> not the expected 0.
> {code:java}
> > Task :geode-assembly:upgradeTest
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[1.10.0]
> FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [e35c359d41713de9: gfsh -e start locator --name=loc2 --port=24585
> --http-service-port=0 --locators=localhost[24583]
> --J=-Dgemfire.jmx-manager-port=24586]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.RollingUpgradeWithGfshDUnitTest.testRollingUpgradeWithDeployment(RollingUpgradeWithGfshDUnitTest.java:107)
> 134 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-results/upgradeTest/1641589807/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0767/test-artifacts/1641589807/upgradetestfiles-openjdk8-1.15.0-build.0767.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-9644) ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects FAILED
[
https://issues.apache.org/jira/browse/GEODE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17478073#comment-17478073
]
Jinmei Liao edited comment on GEODE-9644 at 1/18/22, 5:40 PM:
--
have the rule not to use ephemeral port
was (Author: jinmeiliao):
have the rule not to use empheral port
> ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects
> FAILED
> --
>
> Key: GEODE-9644
> URL: https://issues.apache.org/jira/browse/GEODE-9644
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> There is sequence of cascading exceptions that occur in the VMs and we need a
> more detailed investigation: Possible culprit may be the bind address in use
> exeception:
> [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0513/test-results/distributedTest/1632566050/*]
>
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest$$Lambda$163/1450009752.run
> in VM 0 running on Host
> heavy-lifter-2c03c48d-8a0c-58ae-bad6-31f64bb5400a.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.waitForLocatorToReconnect(ClusterConfigLocatorRestartDUnitTest.java:225)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects(ClusterConfigLocatorRestartDUnitTest.java:90)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> was not fulfilled within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:908)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.lambda$waitForLocatorToReconnect$f182e747$2(ClusterConfigLocatorRestartDUnitTest.java:226)
> 8300 tests completed, 1 failed, 413 skipped{noformat}
> VM2 mentions that cluster membership has failed.
> {noformat}
> [vm2] [info 2021/09/25 09:36:44.487 UTC server-2
> tid=0x153] cluster membership failed due to
> [vm2]
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> for testing
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1787)
> [vm2] at
> org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper.crashDistributedSystem(MembershipManagerHelper.java:139)
> [vm2] at
> org.apache.geode.test.junit.rules.MemberStarterRule.forceDisconnectMember(MemberStarterRule.java:568)
> [vm2] at
> org.apache.geode.test.dunit.rules.MemberVM.lambda$forceDisconnect$bb17a952$1(MemberVM.java:90)
> [vm2] at
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
> [vm2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm2] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm2] at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> [vm2] at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at
[jira] [Resolved] (GEODE-9644) ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects FAILED
[
https://issues.apache.org/jira/browse/GEODE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-9644.
Fix Version/s: 1.15.0
Resolution: Fixed
have the rule not to use empheral port
> ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects
> FAILED
> --
>
> Key: GEODE-9644
> URL: https://issues.apache.org/jira/browse/GEODE-9644
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> There is sequence of cascading exceptions that occur in the VMs and we need a
> more detailed investigation: Possible culprit may be the bind address in use
> exeception:
> [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0513/test-results/distributedTest/1632566050/*]
>
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest$$Lambda$163/1450009752.run
> in VM 0 running on Host
> heavy-lifter-2c03c48d-8a0c-58ae-bad6-31f64bb5400a.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.waitForLocatorToReconnect(ClusterConfigLocatorRestartDUnitTest.java:225)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects(ClusterConfigLocatorRestartDUnitTest.java:90)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> was not fulfilled within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:908)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.lambda$waitForLocatorToReconnect$f182e747$2(ClusterConfigLocatorRestartDUnitTest.java:226)
> 8300 tests completed, 1 failed, 413 skipped{noformat}
> VM2 mentions that cluster membership has failed.
> {noformat}
> [vm2] [info 2021/09/25 09:36:44.487 UTC server-2
> tid=0x153] cluster membership failed due to
> [vm2]
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> for testing
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1787)
> [vm2] at
> org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper.crashDistributedSystem(MembershipManagerHelper.java:139)
> [vm2] at
> org.apache.geode.test.junit.rules.MemberStarterRule.forceDisconnectMember(MemberStarterRule.java:568)
> [vm2] at
> org.apache.geode.test.dunit.rules.MemberVM.lambda$forceDisconnect$bb17a952$1(MemberVM.java:90)
> [vm2] at
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
> [vm2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm2] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm2] at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> [vm2] at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
>
[jira] [Resolved] (GEODE-9908) Marker message is delivered to the durable client after all the puts messages
[ https://issues.apache.org/jira/browse/GEODE-9908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9908. Fix Version/s: 1.15.0 Resolution: Fixed > Marker message is delivered to the durable client after all the puts messages > - > > Key: GEODE-9908 > URL: https://issues.apache.org/jira/browse/GEODE-9908 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When a durable client with registered interests, connects to the server: > 1. it sends a readyForEvent message to the queue, the sever enqueues a marker > message. > 2. then the server enqueues all the puts messages to the queue. > 3. the client disconnects (either by connection failure or by re-auth failure) > 4. the client reconnects back to another server, the other server makes its > queue primary, and enqueues another marker message. > 5. if the first marker message hasn't been delivered to the client yet, the > queue manager will delete the first marker message since marker messages > should be conflated. Then all puts messages will be delivered before the > marker message, thus the client won't put the values in its client cache. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (GEODE-9908) Marker message is delivered to the durable client after all the puts messages
[ https://issues.apache.org/jira/browse/GEODE-9908 ] Jinmei Liao deleted comment on GEODE-9908: was (Author: jinmeiliao): https://github.com/apache/geode/pull/7213 > Marker message is delivered to the durable client after all the puts messages > - > > Key: GEODE-9908 > URL: https://issues.apache.org/jira/browse/GEODE-9908 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > When a durable client with registered interests, connects to the server: > 1. it sends a readyForEvent message to the queue, the sever enqueues a marker > message. > 2. then the server enqueues all the puts messages to the queue. > 3. the client disconnects (either by connection failure or by re-auth failure) > 4. the client reconnects back to another server, the other server makes its > queue primary, and enqueues another marker message. > 5. if the first marker message hasn't been delivered to the client yet, the > queue manager will delete the first marker message since marker messages > should be conflated. Then all puts messages will be delivered before the > marker message, thus the client won't put the values in its client cache. -- This message was sent by Atlassian Jira (v8.20.1#820001)
