[jira] [Commented] (GEODE-10280) Additional info in Server Status command
[ https://issues.apache.org/jira/browse/GEODE-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550800#comment-17550800 ] ASF subversion and git services commented on GEODE-10280: - Commit 0700975d249a4483378dd716dc6dcb5a9a06e650 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0700975d24 ] GEODE-10280: add Status Message to Status Server Command (#7662) * GEODE-10280: add Status Message to Status Server Command * GEODE-10280: update test after comments > Additional info in Server Status command > > > Key: GEODE-10280 > URL: https://issues.apache.org/jira/browse/GEODE-10280 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > Update "status server" command to additionally print status Message if > present in state "starting". > This could be useful for cases when server is stuck in state "starting" due > to waiting on offline member with newest information. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10280) Additional info in Server Status command
[ https://issues.apache.org/jira/browse/GEODE-10280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-10280. -- Fix Version/s: 1.16.0 Resolution: Fixed > Additional info in Server Status command > > > Key: GEODE-10280 > URL: https://issues.apache.org/jira/browse/GEODE-10280 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Update "status server" command to additionally print status Message if > present in state "starting". > This could be useful for cases when server is stuck in state "starting" due > to waiting on offline member with newest information. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10365) Add missing configuration properties to table
[
https://issues.apache.org/jira/browse/GEODE-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Hufnagel updated GEODE-10365:
-
Description: Add ssl-keystore-type, ssl-truststore-type to appropriate
table in
[https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html]
(was: Add *{*}ssl-keystore-type, ssl-truststore-type{*}* to appropriate table
in
[https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html])
> Add missing configuration properties to table
> -
>
> Key: GEODE-10365
> URL: https://issues.apache.org/jira/browse/GEODE-10365
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Affects Versions: 1.12.9, 1.14.5, 1.15.0
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
>
> Add ssl-keystore-type, ssl-truststore-type to appropriate table in
> [https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10365) Add missing configuration properties to table
[
https://issues.apache.org/jira/browse/GEODE-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Hufnagel updated GEODE-10365:
-
Description: Add *{*}ssl-keystore-type, ssl-truststore-type{*}* to
appropriate table in
[https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html]
(was: Add **ssl-keystore-type, ssl-truststore-type** to appropriate tables in
the following:
[https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html]
[https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html])
> Add missing configuration properties to table
> -
>
> Key: GEODE-10365
> URL: https://issues.apache.org/jira/browse/GEODE-10365
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Affects Versions: 1.12.9, 1.14.5, 1.15.0
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
>
> Add *{*}ssl-keystore-type, ssl-truststore-type{*}* to appropriate table in
> [https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10365) Add missing configuration properties to table
[ https://issues.apache.org/jira/browse/GEODE-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Hufnagel reassigned GEODE-10365: Assignee: Max Hufnagel > Add missing configuration properties to table > - > > Key: GEODE-10365 > URL: https://issues.apache.org/jira/browse/GEODE-10365 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.12.9, 1.14.5, 1.15.0 >Reporter: Max Hufnagel >Assignee: Max Hufnagel >Priority: Major > > Add **ssl-keystore-type, ssl-truststore-type** to appropriate tables in the > following: > [https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html] > [https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10365) Add missing configuration properties to table
Max Hufnagel created GEODE-10365: Summary: Add missing configuration properties to table Key: GEODE-10365 URL: https://issues.apache.org/jira/browse/GEODE-10365 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.12.9, 1.14.5, 1.15.0 Reporter: Max Hufnagel Add **ssl-keystore-type, ssl-truststore-type** to appropriate tables in the following: [https://geode.apache.org/docs/guide/112/managing/security/implementing_ssl.html] [https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550712#comment-17550712 ] ASF subversion and git services commented on GEODE-8977: Commit f05ef0d36322ac229bdfe790a89bc2e1b439645b in geode's branch refs/heads/support/1.15 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f05ef0d363 ] GEODE-8977: change ThreadMonitor to reduce how long it does a "stop the world" ThreadDump vm op (#7751) Now uses a cheaper getThreadInfo that does not get lock info by default and calls getThreadInfo for each stuck thread. These are the defaults because they have the shortest time do the the VM ThreadDump operation. To get locks set the system property "gemfire.threadmonitor.showLocks" to "true". To get ThreadInfo on all stuck threads with a single call set the system property "gemfire.threadmonitor.batchCalls" to "true". (cherry picked from commit 3df1e76ddbf2ab8f95e4b337b99b65117054af76) > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-8977: Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI blocks-1.15.0 pull-request-available) > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550710#comment-17550710 ] Darrel Schneider commented on GEODE-8977: - We figured out that getThreadInfo is an expensive VM ThreadDump operation that on most JVMs is done in a global safepoint. This means that all other threads are paused (once each of them reaches a safepoint in their execution) and then the ThreadDump is done. This can cause what appears to be a gc stop the world collection. To reduce the amount of time spend doing the ThreadDump operation, by default geode will not ask for lock/sync info but instead just get the stack trace. Also by default it will do the ThreadDump op on each stuck thread individually instead of with a single call that is passed all the thread ids. This reduces the amount of time spent in the op and on Java 15 and later it uses a thread-local safepoint instead of a global safepoint. To get locks set the system property "gemfire.threadmonitor.showLocks" to "true". To get ThreadInfo on all stuck threads with a single call set the system property "gemfire.threadmonitor.batchCalls" to "true". > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8977. - Fix Version/s: 1.16.0 Resolution: Fixed > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550699#comment-17550699 ] ASF subversion and git services commented on GEODE-8977: Commit 3df1e76ddbf2ab8f95e4b337b99b65117054af76 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3df1e76ddb ] GEODE-8977: change ThreadMonitor to reduce how long it does a "stop the world" ThreadDump vm op (#7751) Now uses a cheaper getThreadInfo that does not get lock info by default and calls getThreadInfo for each stuck thread. These are the defaults because they have the shortest time do the the VM ThreadDump operation. To get locks set the system property "gemfire.threadmonitor.showLocks" to "true". To get ThreadInfo on all stuck threads with a single call set the system property "gemfire.threadmonitor.batchCalls" to "true". > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9704) When durable clients recovers, it sends "ready for event" signal before register for interest, this might cause problem for caching_proxy regions
[ https://issues.apache.org/jira/browse/GEODE-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9704: Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI blocks-1.15.1 pull-request-available) > When durable clients recovers, it sends "ready for event" signal before > register for interest, this might cause problem for caching_proxy regions > - > > Key: GEODE-9704 > URL: https://issues.apache.org/jira/browse/GEODE-9704 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Jinmei Liao >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > This is the old Geode behavior, but may or may not be the correct behavior. > When durable clients recovers, there is a queueTimer thread that runs > `QueueManagerImp.recoverPrimary` method, it > * makes new connection to server > - sends readyForEvents (which will cause the server to start sending the > queued events) > - recovers interest > - clears the region of keys of interest > - re-registers interest > It sends readyForEvents before it clears region of keys of interest, if > server sends some events of those keys in between, it will clear them, thus > it seems to the user that the client region doesn't have those keys. > > Run geode-core distributedTest > AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyKeys_durableClient(), > change the InterestResultPolicy to NONE, you would see the test would fail > occasionally, Adding sleep code in QueueManagerImp.recoverPrimary between > `createNewPrimary` and `recoverInterest` would make the test fail more > consistently. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[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=17550689#comment-17550689
]
ASF subversion and git services commented on GEODE-10304:
-
Commit b7d00dd1d0b43e7983a8d6e66156d6c6712d1eda in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b7d00dd1d0 ]
GEODE-10304: locator thread should not exit after reconnecting (#7697)
* Also refactor ReconnectDUnitTest to use lamdas instead of `Callable` and
`Runnable` interfaces.
> 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
>
> {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
>
[jira] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Priority: Minor (was: Major)
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: needsTriage
>
> 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] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Component/s: tests
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management, tests
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: needsTriage
>
> 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] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Component/s: rest (admin)
> 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
>Priority: Minor
> Labels: needsTriage
>
> 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] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10364:
--
Labels: needsTriage (was: )
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: needsTriage
>
> 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-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550693#comment-17550693
]
Udo Kohlmeyer commented on GEODE-8983:
--
created https://issues.apache.org/jira/browse/GEODE-10364 to track the new issue
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
Udo Kohlmeyer created GEODE-10364:
-
Summary:
DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
Key: GEODE-10364
URL: https://issues.apache.org/jira/browse/GEODE-10364
Project: Geode
Issue Type: Bug
Components: management
Affects Versions: 1.15.0
Reporter: Udo Kohlmeyer
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??
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550692#comment-17550692
]
Udo Kohlmeyer commented on GEODE-8983:
--
Seems the fuzzy logic has picked the wrong ticket to assign a failure to. The
above failures are not caused by the issue this ticket was opened for.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-8983.
--
Resolution: Fixed
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-8983:
-
Labels: (was: pull-request-available)
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-8983:
-
Priority: Minor (was: Major)
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[ https://issues.apache.org/jira/browse/GEODE-8983 ]
Udo Kohlmeyer deleted comment on GEODE-8983:
--
was (Author: ukohlmeyer):
dropping severity on this bug. Given that the problem has to do with the
content that is being logged out (logging the jar file bytes) into the log.
This is causing the DUnit's log watcher to be upset.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550691#comment-17550691
]
Udo Kohlmeyer commented on GEODE-8983:
--
dropping severity on this bug. Given that the problem has to do with the
content that is being logged out (logging the jar file bytes) into the log.
This is causing the DUnit's log watcher to be upset.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550664#comment-17550664
]
Geode Integration commented on GEODE-9340:
--
Seen on support/1.14 in [benchmark-with-security-manager
#69|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/benchmark-with-security-manager/builds/69].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Commented] (GEODE-10167) CI failure: RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
[
https://issues.apache.org/jira/browse/GEODE-10167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550663#comment-17550663
]
Geode Integration commented on GEODE-10167:
---
Seen in [upgrade-test-openjdk11
#386|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/386]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0313/test-results/upgradeTest/1654510296/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0313/test-artifacts/1654510296/upgradetestfiles-openjdk11-1.16.0-build.0313.tgz].
> CI failure:
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> > luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> ---
>
> Key: GEODE-10167
> URL: https://issues.apache.org/jira/browse/GEODE-10167
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {code:java}
> RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> >
> luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled[from_v1.8.0,
> with reindex=false, singleHopEnabled=true] FAILED
> 00:24:01org.gradle.internal.exceptions.DefaultMultiCauseException:
> Multiple Failures (2 failures)
> 00:24:01 org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase$$Lambda$422/0x000100379c40.run
> in VM 2 running on Host
> heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9.c.apachegeode-ci.internal
> with 4 VMs
> 00:24:01 java.lang.AssertionError: Suspicious strings were written to
> the log during this run.
> 00:24:01Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 00:24:01
> ---
> 00:24:01Found suspect string in 'dunit_suspect-vm2.log' at line 3243
> 00:24:01
> 00:24:01[fatal 2022/03/25 07:23:55.137 UTC receiver,heavy-lifter-138290eb-3fbe-5801-8565-60d3c24284e9-23002> tid=49]
> Membership service failure: Member isn't responding to heartbeat requests
> 00:24:01
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> 00:24:01 at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> 00:24:01 at org.jgroups.JChannel.up(JChannel.java:741)
> 00:24:01 at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> 00:24:01 at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> 00:24:01 at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> 00:24:01 at
> org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> 00:24:01 at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> 00:24:01 at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> 00:24:01 at
> org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> 00:24:01 at
> org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> 00:24:01 at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> 00:24:01 at org.jgroups.protocols.TP.receive(TP.java:1714)
> 00:24:01 at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
> 00:24:01 at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 00:24:01 at java.base/java.lang.Thread.run(Thread.java:829)
> 00:24:01at
>
[jira] [Resolved] (GEODE-6021) Introducing Lombok
[ https://issues.apache.org/jira/browse/GEODE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-6021. -- Resolution: Won't Do > Introducing Lombok > -- > > Key: GEODE-6021 > URL: https://issues.apache.org/jira/browse/GEODE-6021 > Project: Geode > Issue Type: Improvement >Reporter: Aditya Anchuri >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Want to introduce Lombok into the Geode code. [https://projectlombok.org/] > We see the following advantages of using Lombok: > -> Less boilerplate code, reduces the size of some classes significantly. > -> Can use builder pattern implicitly, which allows for much better > composeability of an object. > -> Increased readability > More details: [https://projectlombok.org/features/all > ]PR: https://github.com/apache/geode/pull/2815 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars
[
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10342:
-
Fix Version/s: 1.16.0
> Update the HTTP Module for Tomcat instructions to include current required
> jars
> ---
>
> Key: GEODE-10342
> URL: https://issues.apache.org/jira/browse/GEODE-10342
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.5, 1.15.0, 1.16.0
>
>
> Step 6 of the installation instructions tell the user to:
> Copy the following jar files from the Tanzu GemFire {{lib}} subdirectory to
> the {{lib}} subdirectory of your Tomcat server ({{{}$CATALINA_HOME/lib{}}}),
> adding version numbers to the filenames as needed:
> * commons-io jar
> * commons-lang jar
> * commons-validator jar
> * fastutil jar
> * geode-common jar
> * geode-core jar
> * geode-logging jar
> * geode-management jar
> * geode-membership jar
> * geode-serialization jar
> * geode-tcp-server jar
> * javax.transaction-api jar
> * jgroups jar
> * log4j-api jar
> * log4j-core jar
> * log4j-jul jar
> * micrometer-core jar
> * shiro-core jar
> This list is dated and does not include all the libraries that are mentioned
> as dependancies of this jars. For instance, the manifest for geode-core lists
> many jars as dependancies in it’s classpath that are not in the above list
> (e.g. antlr-2.7.7.jar, snappy-0.4.jar, etc.):
> {{
> Manifest-Version: 1.0 2Automatic-Module-Name: io.pivotal.gemfire.core
> 3Organization: VMware, Inc. 4Dependent-Modules: geode-membership-9.10.14
> geode-http-service-9.10.14 5 geode-management-9.10.14 geode-unsafe-9.10.14
> 6Module-Name: geode-core 7Class-Path: antlr-2.7.7.jar commons-io-2.6.jar
> micrometer-core-1.6.3.j 8 ar javax.resource-api-1.7.1.jar
> shiro-core-1.8.0.jar jaxb-api-2.3.1.j 9 ar jaxb-impl-2.3.2.jar
> commons-modeler-2.0.1.jar javax.mail-api-1.6.2 10 .jar mx4j-3.0.2.jar
> mx4j-remote-3.0.2.jar mx4j-tools-3.0.1.jar jna-pl 11 atform-5.5.0.jar
> jna-5.5.0.jar jopt-simple-5.0.4.jar snappy-0.4.jar c 12 lassgraph-4.8.52.jar
> rmiio-2.1.2.jar javax.activation-1.2.0.jar istac 13
> k-commons-runtime-3.0.9.jar swagger-annotations-1.5.23.jar shiro-conf 14
> ig-ogdl-1.8.0.jar shiro-cache-1.8.0.jar shiro-crypto-hash-1.8.0.jar s 15
> hiro-crypto-cipher-1.8.0.jar shiro-config-core-1.8.0.jar shiro-event- 16
> 1.8.0.jar shiro-crypto-core-1.8.0.jar shiro-lang-1.8.0.jar slf4j-api- 17
> 1.7.28.jar javax.activation-api-1.2.0.jar HdrHistogram-2.1.12.jar Lat 18
> encyUtils-2.0.3.jar javax.transaction-api-1.3.jar 19Title: geode 20Version:
> 9.10.14 21Created-By: root
> }}and geode-common
> {{
> 1Manifest-Version: 1.02Organization: VMware,
> Inc.3Dependent-Modules:4Module-Name: geode-common5Class-Path:
> jackson-databind-2.10.5.1.jar jackson-annotations-2.10.5.j6 ar
> jackson-core-2.10.5.jar7Title: geode8Version: 9.10.149Created-By: root}}
> A fully exhaustive list has not yet been determined and confirmed, but it
> should be almost all the jars provided in the distribution’s “lib” directory
> (the classpath of the geode-dependencies meta-jar gives, perhaps, the most
> concise list).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10363) Add geode-deployment-legacy.jar to list of jar files to copy
Max Hufnagel created GEODE-10363: Summary: Add geode-deployment-legacy.jar to list of jar files to copy Key: GEODE-10363 URL: https://issues.apache.org/jira/browse/GEODE-10363 Project: Geode Issue Type: Improvement Affects Versions: 1.15.0 Reporter: Max Hufnagel Add the geode-deployment-legacy.jar to the list of jars on these pages in 1.15: * [https://geode.apache.org/docs/guide/114/tools_modules/http_session_mgmt/tomcat_installing_the_module.html] * [https://geode.apache.org/docs/guide/114/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars
[
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Hufnagel resolved GEODE-10342.
--
Fix Version/s: 1.14.5
1.15.0
Resolution: Fixed
> Update the HTTP Module for Tomcat instructions to include current required
> jars
> ---
>
> Key: GEODE-10342
> URL: https://issues.apache.org/jira/browse/GEODE-10342
> Project: Geode
> Issue Type: Improvement
> Components: docs
>Affects Versions: 1.14.4
>Reporter: Max Hufnagel
>Assignee: Max Hufnagel
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.5, 1.15.0
>
>
> Step 6 of the installation instructions tell the user to:
> Copy the following jar files from the Tanzu GemFire {{lib}} subdirectory to
> the {{lib}} subdirectory of your Tomcat server ({{{}$CATALINA_HOME/lib{}}}),
> adding version numbers to the filenames as needed:
> * commons-io jar
> * commons-lang jar
> * commons-validator jar
> * fastutil jar
> * geode-common jar
> * geode-core jar
> * geode-logging jar
> * geode-management jar
> * geode-membership jar
> * geode-serialization jar
> * geode-tcp-server jar
> * javax.transaction-api jar
> * jgroups jar
> * log4j-api jar
> * log4j-core jar
> * log4j-jul jar
> * micrometer-core jar
> * shiro-core jar
> This list is dated and does not include all the libraries that are mentioned
> as dependancies of this jars. For instance, the manifest for geode-core lists
> many jars as dependancies in it’s classpath that are not in the above list
> (e.g. antlr-2.7.7.jar, snappy-0.4.jar, etc.):
> {{
> Manifest-Version: 1.0 2Automatic-Module-Name: io.pivotal.gemfire.core
> 3Organization: VMware, Inc. 4Dependent-Modules: geode-membership-9.10.14
> geode-http-service-9.10.14 5 geode-management-9.10.14 geode-unsafe-9.10.14
> 6Module-Name: geode-core 7Class-Path: antlr-2.7.7.jar commons-io-2.6.jar
> micrometer-core-1.6.3.j 8 ar javax.resource-api-1.7.1.jar
> shiro-core-1.8.0.jar jaxb-api-2.3.1.j 9 ar jaxb-impl-2.3.2.jar
> commons-modeler-2.0.1.jar javax.mail-api-1.6.2 10 .jar mx4j-3.0.2.jar
> mx4j-remote-3.0.2.jar mx4j-tools-3.0.1.jar jna-pl 11 atform-5.5.0.jar
> jna-5.5.0.jar jopt-simple-5.0.4.jar snappy-0.4.jar c 12 lassgraph-4.8.52.jar
> rmiio-2.1.2.jar javax.activation-1.2.0.jar istac 13
> k-commons-runtime-3.0.9.jar swagger-annotations-1.5.23.jar shiro-conf 14
> ig-ogdl-1.8.0.jar shiro-cache-1.8.0.jar shiro-crypto-hash-1.8.0.jar s 15
> hiro-crypto-cipher-1.8.0.jar shiro-config-core-1.8.0.jar shiro-event- 16
> 1.8.0.jar shiro-crypto-core-1.8.0.jar shiro-lang-1.8.0.jar slf4j-api- 17
> 1.7.28.jar javax.activation-api-1.2.0.jar HdrHistogram-2.1.12.jar Lat 18
> encyUtils-2.0.3.jar javax.transaction-api-1.3.jar 19Title: geode 20Version:
> 9.10.14 21Created-By: root
> }}and geode-common
> {{
> 1Manifest-Version: 1.02Organization: VMware,
> Inc.3Dependent-Modules:4Module-Name: geode-common5Class-Path:
> jackson-databind-2.10.5.1.jar jackson-annotations-2.10.5.j6 ar
> jackson-core-2.10.5.jar7Title: geode8Version: 9.10.149Created-By: root}}
> A fully exhaustive list has not yet been determined and confirmed, but it
> should be almost all the jars provided in the distribution’s “lib” directory
> (the classpath of the geode-dependencies meta-jar gives, perhaps, the most
> concise list).
--
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=17550621#comment-17550621
]
Geode Integration commented on GEODE-6489:
--
Seen in [distributed-test-openjdk8
#2626|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2626]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654324865/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654324865/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> 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
>
> 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-6489) CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550622#comment-17550622
]
Geode Integration commented on GEODE-6489:
--
Seen in [distributed-test-openjdk8
#2612|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2612]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654317431/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654317431/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> 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
>
> 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] [Updated] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Fix Version/s: 1.16.0 > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-9615.
--
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
in develop and
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
in support/1.15
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.15.0, 1.16.0
>
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
>
[jira] [Updated] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9615:
-
Affects Version/s: 1.14.0
1.13.0
1.15.0
1.16.0
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --name=locator-chase-obedient-cake]] expected:<[0]> but was:<[1]>
> at
>
[jira] [Resolved] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10327. --- Fix Version/s: 1.15.0 Resolution: Fixed Fixed by https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629 in develop and https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b in support/1.15 > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550613#comment-17550613
]
Kirk Lund edited comment on GEODE-10360 at 6/6/22 7:08 PM:
---
Sorry for confusion, my changes in
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
did not fix GEODE-10360
was (Author: klund):
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
and backported to 1.15 in
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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
>
[jira] [Reopened] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reopened GEODE-10360:
---
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
> Fix For: 1.15.0
>
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10360:
--
Fix Version/s: (was: 1.15.0)
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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] [Resolved] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-10360.
---
Fix Version/s: 1.15.0
Resolution: Fixed
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
and backported to 1.15 in
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
> Fix For: 1.15.0
>
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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
>
[jira] [Commented] (GEODE-10155) ServerConnection thread hangs when client function execution times-out
[ https://issues.apache.org/jira/browse/GEODE-10155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550606#comment-17550606 ] ASF subversion and git services commented on GEODE-10155: - Commit 7ccdc8297b1ded06175f41543884d945d5995c60 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7ccdc8297b ] GEODE-10155: Avoid threads hanging when function execution times-out (#7493) * GEODE-10155: Avoid threads hanging when function execution times-out * GEODE-10155: Updated after review * GEODE-10155: More changes after review * GEODE-10155: Changes after more reviews * GEODE-10155: Some more changes after review * GEODE-10155: More changes after review * GEODE-10155: More clean-up after review > ServerConnection thread hangs when client function execution times-out > -- > > Key: GEODE-10155 > URL: https://issues.apache.org/jira/browse/GEODE-10155 > Project: Geode > Issue Type: Bug > Components: core, functions >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > If a Geode client executes a non-HA server function (isHA=false) with a > timeout > and > the function is handled in the Geode server by a "Function Execution > Processor" thread (for example by calling the function with onRegion() on a > partitioned region without a filter) > and > the function times-out before the server has answered back with all the > results > then > the ServerConnection thread that originally started to handle the function > execution will be stuck forever. > > If this happens several times and the max-threads parameters is set to a > value greater than 0, the server will eventually run out of ServerConnection > threads and will not be able to process more client requests. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10362) Expose gateway sender recovery status, after restart of server
[ https://issues.apache.org/jira/browse/GEODE-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-10362: Assignee: Mario Ivanac > Expose gateway sender recovery status, after restart of server > -- > > Key: GEODE-10362 > URL: https://issues.apache.org/jira/browse/GEODE-10362 > Project: Geode > Issue Type: Wish > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > > Expose gateway sender recovery status, after restart of server -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10362) Expose gateway sender recovery status, after restart of server
Mario Ivanac created GEODE-10362: Summary: Expose gateway sender recovery status, after restart of server Key: GEODE-10362 URL: https://issues.apache.org/jira/browse/GEODE-10362 Project: Geode Issue Type: Wish Components: wan Reporter: Mario Ivanac Expose gateway sender recovery status, after restart of server -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10106:
--
Labels: pull-request-available (was: blocks-1.15.0 pull-request-available)
> 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: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.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
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
>
[jira] [Updated] (GEODE-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException
[
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10361:
--
Labels: blocks-1.16.0 (was: needsTriage)
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators
> with NoAvailableLocatorsException
> --
>
> Key: GEODE-10361
> URL: https://issues.apache.org/jira/browse/GEODE-10361
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown FAILED
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to
> connect to any locators in the list
> [heavy-lifter-972eb062-9b0f-52e1-a58b-0dd44f11dbcc:27503]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:159)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImplIntegrationTest.test_DiscoverLocators_whenOneLocatorWasShutdown(AutoConnectionSourceImplIntegrationTest.java:317)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10360:
--
Labels: blocks-1.16.0 (was: needsTriage)
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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] [Updated] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10351:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> [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: 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] [Updated] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10351:
--
Labels: blocks-1.16.0 pull-request-available (was: pull-request-available)
> [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
>
> {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] [Updated] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
[
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-1957:
-
Labels: blocks-1.16.0 (was: needsTriage)
> CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
>
>
> Key: GEODE-1957
> URL: https://issues.apache.org/jira/browse/GEODE-1957
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.16.0
>
> This test failed in a CI run with SHA 7254cf3fb0ceb2255650d96f2b0ed615118ef700
> {noformat}
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest >
> testCloseOpenRegion FAILED
> java.lang.AssertionError: Failed on entry 40 expected: but was:
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest.checkEntriesInMemory(DiskRegionAsyncRecoveryJUnitTest.java:456)
> at
> org.apache.geode.internal.cache.DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion(DiskRegionAsyncRecoveryJUnitTest.java:382)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10354) Convert DataPolicy and InterestPolicy to enums
[
https://issues.apache.org/jira/browse/GEODE-10354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10354:
---
Labels: pull-request-available (was: )
> Convert DataPolicy and InterestPolicy to enums
> --
>
> Key: GEODE-10354
> URL: https://issues.apache.org/jira/browse/GEODE-10354
> Project: Geode
> Issue Type: Improvement
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: pull-request-available
>
> Both {{DataPolicy}} and {{InterestPolicy}} are enum like classes so make them
> true Java enums.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.
[ https://issues.apache.org/jira/browse/GEODE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10301: - Fix Version/s: 1.15.0 > Allow users to have java.time.* types (like LocalDateTime, LocalDate, and > LocalTime) in their query result fields. > --- > > Key: GEODE-10301 > URL: https://issues.apache.org/jira/browse/GEODE-10301 > Project: Geode > Issue Type: Improvement >Reporter: John Martin >Assignee: Joris Melchior >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Users with java.time.* types (like LocalDateTime, LocalDate, and LocalTime) > in their query result fields will need to have, *jackson-datatype-jsr310* > and/or *jackson-datatype-joda* in the runtime classpath to have the proper > formatting. This currently requires users to manually add these classes. > > To improve the user experience we should include these in the release. We > should match the version of jackson-core that we release with. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.
[ https://issues.apache.org/jira/browse/GEODE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550580#comment-17550580 ] ASF subversion and git services commented on GEODE-10301: - Commit 3c9bb2e4575554a4ab5556e98e6e6a7324ef034f in geode's branch refs/heads/support/1.15 from Joris Melchior [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3c9bb2e457 ] GEODE-10301: support LocalDate and JodaTime (#7737) * GEODE-10301: support LocalDate and JodaTime Co-authored-by: Jinmei Liao - include libraries so that end-users won't have to add them to the java path - ensure proper serialization in gfsh and pulse (cherry picked from commit e370d2fb6c9f5e4281146fe78a4840452f70ca9e) > Allow users to have java.time.* types (like LocalDateTime, LocalDate, and > LocalTime) in their query result fields. > --- > > Key: GEODE-10301 > URL: https://issues.apache.org/jira/browse/GEODE-10301 > Project: Geode > Issue Type: Improvement >Reporter: John Martin >Assignee: Joris Melchior >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > Users with java.time.* types (like LocalDateTime, LocalDate, and LocalTime) > in their query result fields will need to have, *jackson-datatype-jsr310* > and/or *jackson-datatype-joda* in the runtime classpath to have the proper > formatting. This currently requires users to manually add these classes. > > To improve the user experience we should include these in the release. We > should match the version of jackson-core that we release with. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6222.
--
Resolution: Fixed
GEODE-6222 has been replaced by GEODE-6489.
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> 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:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-6489) CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6489:
-
Summary: CI Failures with GemFireDeadlockDetectorDUnitTest >
testDistributedDeadlock (was: CI Failures with testDistributedDeadlock)
> 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
>
> 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-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550576#comment-17550576 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2616|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2616] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654316309/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654316309/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550574#comment-17550574 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2627|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2627] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654325579/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654325579/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag closed GEODE-10106.
---
> 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: Nabarun Nag
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.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
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> 11:49:39at
>
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550575#comment-17550575 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2601|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2601] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654307956/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654307956/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550573#comment-17550573 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2630|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2630] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654326083/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654326083/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag resolved GEODE-10106.
-
Fix Version/s: 1.16.0
Resolution: Fixed
b16dafa7128ec3a766f4edaa4d7e770113cddeb9
> 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: Nabarun Nag
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.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
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> 11:49:39at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 11:49:39at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> 11:49:39at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> 11:49:39at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> 11:49:39at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> 11:49:39at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> 11:49:39at
>
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550571#comment-17550571 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2679|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2679] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654368176/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654368176/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550572#comment-17550572 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2649|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2649] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654341853/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654341853/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550570#comment-17550570 ] Geode Integration commented on GEODE-7739: -- Seen in [distributed-test-openjdk8 #2688|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2688] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654377051/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654377051/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550568#comment-17550568
]
Geode Integration commented on GEODE-7822:
--
Seen in [distributed-test-openjdk8
#2623|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2623]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654325041/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654325041/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550567#comment-17550567
]
Geode Integration commented on GEODE-8983:
--
Seen in [distributed-test-openjdk8
#2671|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654364484/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654364484/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 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.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550569#comment-17550569
]
Geode Integration commented on GEODE-7822:
--
Seen in [distributed-test-openjdk8
#2615|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2615]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654317685/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654317685/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550566#comment-17550566
]
Geode Integration commented on GEODE-7822:
--
Seen in [distributed-test-openjdk8
#2671|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-results/distributedTest/1654364484/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0311/test-artifacts/1654364484/distributedtestfiles-openjdk8-1.16.0-build.0311.tgz].
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag reassigned GEODE-10360:
---
Assignee: Nabarun Nag
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> 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.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] [Resolved] (GEODE-438) CI failure: MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection
[
https://issues.apache.org/jira/browse/GEODE-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-438.
-
Resolution: Duplicate
GEODE-438 has been replaced by GEODE-7822.
> CI failure: MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection
>
>
> Key: GEODE-438
> URL: https://issues.apache.org/jira/browse/GEODE-438
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Kirk Lund
>Priority: Minor
> Labels: CI, Flaky
>
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$16.call
> in VM 1 running on Host cc6-co6.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:360)
> at dunit.VM.invoke(VM.java:303)
> at dunit.VM.invoke(VM.java:271)
> at
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:558)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: junit.framework.AssertionFailedError: Event never occurred after
> 3000 ms: verify critical state
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
> at
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$16.call(MemoryThresholdsOffHeapDUnitTest.java:610)
> at
[jira] [Commented] (GEODE-10346) Correct batch-time-interval description in documentation
[ https://issues.apache.org/jira/browse/GEODE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550327#comment-17550327 ] ASF subversion and git services commented on GEODE-10346: - Commit d1e21db47f1745b45403daedd9552b569b4bbd7e in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d1e21db47f ] GEODE-10346: Correct description of batch-time-interval in doc. (#7742) > Correct batch-time-interval description in documentation > > > Key: GEODE-10346 > URL: https://issues.apache.org/jira/browse/GEODE-10346 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The description of the batch-time-interval parameter for the Gateway Sender > in the Geode documentation states the following: > "Maximum amount of time, in ms, that can elapse before a batch is delivered." > Nevertheless, that is not completely true. > The number of ms that can elapse before a batch is delivered could be longer > than what is configured in batch-time-interval in the case that the batch > being created has not yet reached the value of max-batch-size and there are > still events in the gateway sender's queue to be added to the batch. If that > is the case, new events will keep being added to the batch without taking > into account the value for batch-time-interval. > The batch-time-interval parameter is only used when the batch being filled > has not reached the max-batch-size but there are no events in the queue. In > that case, in order not to delay the delivery of the batch until there are > events in the queue, this value is used to determine if the batch must be > sent. -- This message was sent by Atlassian Jira (v8.20.7#820007)
