[jira] [Updated] (GEODE-923) CI failure: ConnectionManagerJUnitTest.testIdleExpiration

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-923:

Affects Version/s: 1.14.0
   1.13.0
   1.15.0

> CI failure: ConnectionManagerJUnitTest.testIdleExpiration
> -
>
> Key: GEODE-923
> URL: https://issues.apache.org/jira/browse/GEODE-923
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Sai Boorlagadda
>Assignee: Kirk Lund
>Priority: Major
>  Labels: CI, Flaky
>
> Error Message
> {noformat}
> java.lang.AssertionError: Elapsed 238 is less than idle timeout 300
> {noformat}
> Stacktrace
> {noformat}
> java.lang.AssertionError: Elapsed 238 is less than idle timeout 300
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at 
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerJUnitTest.testIdleExpiration(ConnectionManagerJUnitTest.java:282)
>   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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   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 
> 

[jira] [Commented] (GEODE-92) PR with entry eviction 1 leaves 3 entries in memory with async overflow

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547355#comment-17547355
 ] 

Geode Integration commented on GEODE-92:


Seen in [windows-core-integration-test-openjdk8 
#386|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/386]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0305/test-results/integrationTest/1654217268/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0305/test-artifacts/1654217268/windows-coreintegrationtestfiles-openjdk8-1.16.0-build.0305.tgz].

> PR with entry eviction 1 leaves 3 entries in memory with async overflow
> ---
>
> Key: GEODE-92
> URL: https://issues.apache.org/jira/browse/GEODE-92
> Project: Geode
>  Issue Type: Bug
>  Components: eviction
>Reporter: Dan Smith
>Assignee: Sai Boorlagadda
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.0.0-incubating.M3, 1.8.0
>
> Attachments: 
> 0001-Test-that-demonstrates-two-many-entries-in-memory-wi.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I discovered this while working on a unit test for another issue. It appears 
> that when configuring a PR with entry eviction 1, in some cases there ends up 
> being more than 1 entry left in memory when using overflow to disk with 
> disk-synchronous=false.
> With synchronous disk, this issue does not occur.
> A deadlock was also found when doing a put or create on a region with custom 
> expiry callback doing getValue():
> "ServerConnection on port 40404 Thread 1543350" tid=0x5267ad owned by 
> "ServerConnection on port 40404 Thread 1543342" tid=0x52679b
>      java.lang.Thread.State: BLOCKED
>      at 
> org.apache.geode.internal.cache.eviction.AbstractEvictionList.isEvictable(AbstractEvictionList.java:199)
>      -  blocked on 
> org.apache.geode.internal.cache.entries.VersionedStatsLRURegionEntryHeapObjectKey@6027657a
>      at 
> org.apache.geode.internal.cache.eviction.LRUListWithSyncSorting.getEvictableEntry(LRUListWithSyncSorting.java:72)
>      at 
> org.apache.geode.internal.cache.AbstractLRURegionMap.lruUpdateCallback(AbstractLRURegionMap.java:445)
>      at 
> org.apache.geode.internal.cache.LocalRegion.getDeserialized(LocalRegion.java:1276)
>      at 
> org.apache.geode.internal.cache.LocalRegion$ExpiryRegionEntry.getValue(LocalRegion.java:7893)
>      at 
> org.apache.geode.modules.util.SessionCustomExpiry.getExpiry(SessionCustomExpiry.java:38)
>      at 
> org.apache.geode.internal.cache.LocalRegion.createExpiryTask(LocalRegion.java:7995)
>      at 
> org.apache.geode.internal.cache.LocalRegion.addExpiryTask(LocalRegion.java:8109)
>      at 
> org.apache.geode.internal.cache.LocalRegion.addExpiryTaskIfAbsent(LocalRegion.java:7810)
>      at 
> org.apache.geode.internal.cache.LocalRegion.updateStatsForPut(LocalRegion.java:7116)
>      at 
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5739)
>      at 
> org.apache.geode.internal.cache.BucketRegion.basicPutPart2(BucketRegion.java:677)
>      at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2864)
>      -  locked 
> org.apache.geode.internal.cache.entries.VersionedStatsLRURegionEntryHeapObjectKey@4efa554
>      at 
> org.apache.geode.internal.cache.BucketRegion.virtualPut(BucketRegion.java:503)
>      at 
> org.apache.geode.internal.cache.PartitionedRegionDataStore.putLocally(PartitionedRegionDataStore.java:1223)
>      at 
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2819)
>      at 
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2027)
>      at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
>      at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5603)
>      at 
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5240)
>      at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:390)
>      at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
>      at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
>      at 
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
>      at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
>  

[jira] [Updated] (GEODE-9089) Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants Fail

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-9089:
-
Labels:   (was: needsTriage)

> Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants 
> Fail
> -
>
> Key: GEODE-9089
> URL: https://issues.apache.org/jira/browse/GEODE-9089
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Two failures in this CI run: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/106:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest > 
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$151/1201663250.run
>  in VM 2 running on Host d2642cb6ec08 with 8 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.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:757)
> Caused by:
> 00, 899000, 665100, 587000, 518100, 721000, 623100, 551000, 592000, 182100, 
> 779100, 164100, 5104300, 5326300, 297000, 31100, 843000, 910100, 992000, 
> 456100, 190100, 982100, 5517300, 815000, 5411200, 1093000, 657100, 870100, 
> 5210300, 176100, 5065200, 294100, 5521300, 1034000, 570100, 5257200, 827000, 
> 5535200, 77100, 862000, 5419300, 255100, 681000, 348100, 5423200, 5194300, 
> 5416300, 5554200, 5392300, 711000, 857100, 320100, 5449200, 5348300, 5004200, 
> 426100, 111, 5487200, 787000, 884000, 5216200, 5560200, 580100, 861000, 
> 425000, 799100, 5553200, 972100, 5114200, 271000, 5000200, 243000, 172100, 
> 5561200, 262000, 1091100, 477100, 75, 109000, 5431300, 980100, 5237300, 
> 5308300, 5150200, 689000, 207000, 446100, 805100, 5111200, 9000, 00, 
> 5534300, 536100, 5062300, 1082000, 5397200, 798100, 5308200, 553000, 5374300, 
> 703000, 160100, 5560300, 38100, 4100, 678100, 1113100, 973000, 5558300, 
> 5175200, 5188200, 212100, 1007000, 1104000, 467100, 5540200, 809000, 810100, 
> 1106100, 1077100, 69100, 5143200, 776100, 5396200, 113100, 181000, 1094100, 
> 883100, 542100, 5031200, 147100, 481000, 353000, 1050100, 219100, 4000, 
> 576000, 393000, 248100, 5508200, 1012000, 380100, 5166300, 894100, 5398200, 
> 510100, 798000, 5066200, 5189200, 39, 832000, 5377200, 5022300, 311100, 
> 1017100, 383100, 5401200, 266000, 966100, 231000, 5382300, 778000, 276100, 
> 5320300, 529100, 496100, 5256200, 860100, 5360300, 1055100, 5250200, 609100, 
> 553100, 5259300, 5089300, 43, 5565200, 579100, 1065000, 424000, 622100, 
> 157000, 847100, 80100, 5460200, 5124300, 101000, 898100, 5292300, 482100, 
> 5553300, 1074100, 5499300, 554000, 5352200, 5039300, 2000, 667000, 376000, 
> 5143300, 753100, 466000, 5064300, 5006200, 5174200, 744100, 937000, 5145200, 
> 71100, 351100, 5289200, 206100, 805000, 5493200, 431000, 378100, 333100, 
> 5118200, 103100, 462000, 5527200, 5255200, 5033200, 56100, 521100, 8100, 
> 300, 42000, 331100, 5439200, 68, 801100, 65100, 5207300, 479000, 
> 792100, 5004300, 5171300, 318000, 681100, 619100, 955100, 903000, 72000, 
> 5292200, 1044000, 1023100, 323000, 5353300, 558000, 544100, 265000, 5018200, 
> 5340300, 751100, 607000, 582000, 465100, 253100, 935100, 174100, 5043300, 
> 537100, 178000, 1127100, 88100, 661100, 5402200, 3, 958100, 49000, 96100, 
> 979000, 5081300, 5075300, 5206300, 84000, 5154200, 1057100, 5409300, 62000, 
> 506000, 1107100, 5022200, 921000, 448100, 1004100, 427100, 829000, 1107000, 
> 244000, 414000, 74100, 409000, 833100, 77, 51000, 5113300, 908100, 
> 5312300, 5263300, 5148300, 138100, 336100, 1081000, 5365300, 151000, 165000, 
> 759000, 752000, 19, 5460300, 685000, 298100, 566100, 877100, 46, 
> 5108300, 377100, 71, 750100, 95100, 228100, 5116300, 522100, 5110200, 
> 45, 64, 5086200, 683000, 348000, 305000, 797100, 18, 636000, 
> 5494300, 634100, 1072000, 5323200, 737100, 861100, 5426300, 687100, 699100, 
> 684000, 1046100, 332000, 428100, 5498300, 141000, 5088200, 154000, 896000, 
> 1040100, 5182200, 5231300, 5140300, 5259200, 5253300, 1043000, 629100, 
> 365100, 496000, 5490200, 184000, 37000, 5366300, 121100, 5367200, 1102100, 
> 5541200, 534000, 5361200, 1053000, 98100, 5307300, 425100, 5534200, 974000, 
> 847000, 361100, 326000, 5387200, 951000, 381000, 5083300, 768000, 5346200, 
> 1086100, 946100, 411100, 5293200, 52100, 5383200, 1122100, 5297200, 238100, 
> 5027200, 791000, 

[jira] [Updated] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-6504:
-
Labels: GeodeOperationAPI  (was: GeodeOperationAPI needsTriage)

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (GEODE-8589) make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test deterministic

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-8589:
-
Affects Version/s: (was: 1.13.0)
   (was: 1.14.0)

> make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test 
> deterministic
> ---
>
> Key: GEODE-8589
> URL: https://issues.apache.org/jira/browse/GEODE-8589
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>  Labels: membership, pull-request-available
>
> A recent commit added a new test: 
> {{MembershipIntegrationTest.locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}
> That's a good test. But it would be better if it ran faster and was less 
> susceptible to timing issues. The problem is that the logic we are trying to 
> test, {{GMSJoinLeave.leave()}} uses {{System.currentTimeMillis()}} to get the 
> current time and it uses {{Thread.sleep()}} to sleep:
> {code:java}
> long now = System.currentTimeMillis();
> ...
> if (state.joinedMembersContacted <= 0 && ((now >= 
> locatorGiveUpTime &&
> tries >= minimumRetriesBeforeBecomingCoordinator) ||
> state.locatorsContacted >= locators.size())) {
> ...
> if (System.currentTimeMillis() > giveupTime) {
>   break;
> }
> ...
>   Thread.sleep(retrySleep);
> ...
>   giveupTime = System.currentTimeMillis() + timeout;
> ...
>   if (!this.isJoined) {
> logger.debug("giving up attempting to join the distributed system 
> after "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> ...
>   if (!this.isJoined && state.hasContactedAJoinedLocator) {
> throw new MemberStartupException("Unable to join the distributed 
> system in "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> {code}
> The opportunity is to _inject_ objects that handle these two functions (time 
> keeping and sleeping). This will enable us to artifically control these in 
> our test! Sleeping doesn't have to take any time at all. And we can make time 
> pass as quickly as we want to.
> For an example of how this can be done, see [PR 
> #5422|https://github.com/apache/geode/pull/5422] for GEODE-6950.
> This particular test 
> ({{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}) is a 
> little bit more involved than that one in that more objects are involved. In 
> addition to {{GMSJoinLeave}}, other classes involved in the test also need 
> current time and need to sleep.
> When this ticket is complete:
> * functional interfaces {{MillisecondProvider}} and {{Sleeper}}, currently 
> defined inside {{PrimaryHandler}} will be moved higher in the (internal) 
> hierarchy for use by other membership classes
> * {{GMSJoinLeave}} will take a {{MillisecondProvider}} and {{Sleeper}} in its 
> constructor and will delegate to those instead of calling 
> {{System.currentTimeMillis()}} and {{Thread.sleep()}} directly
> * TBD other classes may require injection of {{MillisecondProvider}} and 
> {{Sleeper}}
> * TBD other changes may be necessary in cases where collaborating classes 
> currently spin up threads or synchronize between threads e.g. calling 
> {{wait()}}
> * {{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}} will no 
> longer employ {{Thread.sleep()}} nor will it call 
> {{CompletableFuture.get(long timeout, TimeUnit unit)}}—instead it will 
> operate deterministically (ideally in the same thread but not necessarily) 
> with respect to the unit under test.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (GEODE-8589) make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test deterministic

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-8589:
-
Affects Version/s: 1.14.0
   1.13.0
   1.15.0

> make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test 
> deterministic
> ---
>
> Key: GEODE-8589
> URL: https://issues.apache.org/jira/browse/GEODE-8589
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>  Labels: membership, pull-request-available
>
> A recent commit added a new test: 
> {{MembershipIntegrationTest.locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}
> That's a good test. But it would be better if it ran faster and was less 
> susceptible to timing issues. The problem is that the logic we are trying to 
> test, {{GMSJoinLeave.leave()}} uses {{System.currentTimeMillis()}} to get the 
> current time and it uses {{Thread.sleep()}} to sleep:
> {code:java}
> long now = System.currentTimeMillis();
> ...
> if (state.joinedMembersContacted <= 0 && ((now >= 
> locatorGiveUpTime &&
> tries >= minimumRetriesBeforeBecomingCoordinator) ||
> state.locatorsContacted >= locators.size())) {
> ...
> if (System.currentTimeMillis() > giveupTime) {
>   break;
> }
> ...
>   Thread.sleep(retrySleep);
> ...
>   giveupTime = System.currentTimeMillis() + timeout;
> ...
>   if (!this.isJoined) {
> logger.debug("giving up attempting to join the distributed system 
> after "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> ...
>   if (!this.isJoined && state.hasContactedAJoinedLocator) {
> throw new MemberStartupException("Unable to join the distributed 
> system in "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> {code}
> The opportunity is to _inject_ objects that handle these two functions (time 
> keeping and sleeping). This will enable us to artifically control these in 
> our test! Sleeping doesn't have to take any time at all. And we can make time 
> pass as quickly as we want to.
> For an example of how this can be done, see [PR 
> #5422|https://github.com/apache/geode/pull/5422] for GEODE-6950.
> This particular test 
> ({{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}) is a 
> little bit more involved than that one in that more objects are involved. In 
> addition to {{GMSJoinLeave}}, other classes involved in the test also need 
> current time and need to sleep.
> When this ticket is complete:
> * functional interfaces {{MillisecondProvider}} and {{Sleeper}}, currently 
> defined inside {{PrimaryHandler}} will be moved higher in the (internal) 
> hierarchy for use by other membership classes
> * {{GMSJoinLeave}} will take a {{MillisecondProvider}} and {{Sleeper}} in its 
> constructor and will delegate to those instead of calling 
> {{System.currentTimeMillis()}} and {{Thread.sleep()}} directly
> * TBD other classes may require injection of {{MillisecondProvider}} and 
> {{Sleeper}}
> * TBD other changes may be necessary in cases where collaborating classes 
> currently spin up threads or synchronize between threads e.g. calling 
> {{wait()}}
> * {{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}} will no 
> longer employ {{Thread.sleep()}} nor will it call 
> {{CompletableFuture.get(long timeout, TimeUnit unit)}}—instead it will 
> operate deterministically (ideally in the same thread but not necessarily) 
> with respect to the unit under test.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-1957:
-
Affects Version/s: 1.14.0
   1.13.0
   1.15.0

> 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: Minor
>  Labels: needsTriage
>
> 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-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-1957:
-
Priority: Major  (was: Minor)

> 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: needsTriage
>
> 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-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-1957:
-
Labels: needsTriage  (was: ci flaky)

> CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
> 
>
> Key: GEODE-1957
> URL: https://issues.apache.org/jira/browse/GEODE-1957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Bruce J Schuchardt
>Priority: Minor
>  Labels: needsTriage
>
> 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-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-6504:
-
Labels: GeodeOperationAPI needsTriage  (was: GeodeOperationAPI)

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (GEODE-9089) Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants Fail

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-9089:
-
Labels: needsTriage  (was: )

> Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants 
> Fail
> -
>
> Key: GEODE-9089
> URL: https://issues.apache.org/jira/browse/GEODE-9089
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>  Labels: needsTriage
>
> Two failures in this CI run: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/106:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest > 
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$151/1201663250.run
>  in VM 2 running on Host d2642cb6ec08 with 8 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.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:757)
> Caused by:
> 00, 899000, 665100, 587000, 518100, 721000, 623100, 551000, 592000, 182100, 
> 779100, 164100, 5104300, 5326300, 297000, 31100, 843000, 910100, 992000, 
> 456100, 190100, 982100, 5517300, 815000, 5411200, 1093000, 657100, 870100, 
> 5210300, 176100, 5065200, 294100, 5521300, 1034000, 570100, 5257200, 827000, 
> 5535200, 77100, 862000, 5419300, 255100, 681000, 348100, 5423200, 5194300, 
> 5416300, 5554200, 5392300, 711000, 857100, 320100, 5449200, 5348300, 5004200, 
> 426100, 111, 5487200, 787000, 884000, 5216200, 5560200, 580100, 861000, 
> 425000, 799100, 5553200, 972100, 5114200, 271000, 5000200, 243000, 172100, 
> 5561200, 262000, 1091100, 477100, 75, 109000, 5431300, 980100, 5237300, 
> 5308300, 5150200, 689000, 207000, 446100, 805100, 5111200, 9000, 00, 
> 5534300, 536100, 5062300, 1082000, 5397200, 798100, 5308200, 553000, 5374300, 
> 703000, 160100, 5560300, 38100, 4100, 678100, 1113100, 973000, 5558300, 
> 5175200, 5188200, 212100, 1007000, 1104000, 467100, 5540200, 809000, 810100, 
> 1106100, 1077100, 69100, 5143200, 776100, 5396200, 113100, 181000, 1094100, 
> 883100, 542100, 5031200, 147100, 481000, 353000, 1050100, 219100, 4000, 
> 576000, 393000, 248100, 5508200, 1012000, 380100, 5166300, 894100, 5398200, 
> 510100, 798000, 5066200, 5189200, 39, 832000, 5377200, 5022300, 311100, 
> 1017100, 383100, 5401200, 266000, 966100, 231000, 5382300, 778000, 276100, 
> 5320300, 529100, 496100, 5256200, 860100, 5360300, 1055100, 5250200, 609100, 
> 553100, 5259300, 5089300, 43, 5565200, 579100, 1065000, 424000, 622100, 
> 157000, 847100, 80100, 5460200, 5124300, 101000, 898100, 5292300, 482100, 
> 5553300, 1074100, 5499300, 554000, 5352200, 5039300, 2000, 667000, 376000, 
> 5143300, 753100, 466000, 5064300, 5006200, 5174200, 744100, 937000, 5145200, 
> 71100, 351100, 5289200, 206100, 805000, 5493200, 431000, 378100, 333100, 
> 5118200, 103100, 462000, 5527200, 5255200, 5033200, 56100, 521100, 8100, 
> 300, 42000, 331100, 5439200, 68, 801100, 65100, 5207300, 479000, 
> 792100, 5004300, 5171300, 318000, 681100, 619100, 955100, 903000, 72000, 
> 5292200, 1044000, 1023100, 323000, 5353300, 558000, 544100, 265000, 5018200, 
> 5340300, 751100, 607000, 582000, 465100, 253100, 935100, 174100, 5043300, 
> 537100, 178000, 1127100, 88100, 661100, 5402200, 3, 958100, 49000, 96100, 
> 979000, 5081300, 5075300, 5206300, 84000, 5154200, 1057100, 5409300, 62000, 
> 506000, 1107100, 5022200, 921000, 448100, 1004100, 427100, 829000, 1107000, 
> 244000, 414000, 74100, 409000, 833100, 77, 51000, 5113300, 908100, 
> 5312300, 5263300, 5148300, 138100, 336100, 1081000, 5365300, 151000, 165000, 
> 759000, 752000, 19, 5460300, 685000, 298100, 566100, 877100, 46, 
> 5108300, 377100, 71, 750100, 95100, 228100, 5116300, 522100, 5110200, 
> 45, 64, 5086200, 683000, 348000, 305000, 797100, 18, 636000, 
> 5494300, 634100, 1072000, 5323200, 737100, 861100, 5426300, 687100, 699100, 
> 684000, 1046100, 332000, 428100, 5498300, 141000, 5088200, 154000, 896000, 
> 1040100, 5182200, 5231300, 5140300, 5259200, 5253300, 1043000, 629100, 
> 365100, 496000, 5490200, 184000, 37000, 5366300, 121100, 5367200, 1102100, 
> 5541200, 534000, 5361200, 1053000, 98100, 5307300, 425100, 5534200, 974000, 
> 847000, 361100, 326000, 5387200, 951000, 381000, 5083300, 768000, 5346200, 
> 1086100, 946100, 411100, 5293200, 52100, 5383200, 1122100, 

[jira] [Updated] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-6504:
-
Affects Version/s: 1.14.0
   1.13.0
   1.15.0

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Assigned] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-10323:
-

Assignee: Alberto Gomez

> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: 
> expected:<100> but was:<1048576>
> 
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Assignee: Alberto Gomez
>Priority: Major
>  Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for 
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing 
> intermittently due to commit a350ed2 which went in as 
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance 
> off-heap fragmentation visibility. 
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at 
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor 
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the 
> constructor which immediately gets scheduled to invoke 
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of 
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of 
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and 
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a 
> bad practice and should only be done via some sort of activation method such 
> as {{start()}} which can be invoked from the static factory method for 
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct 
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other 
> tests, is written with the assumption that no other thread or component can 
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test 
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219:  stats.setLargestFragment(100);
> 220:  assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because 
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and 
> changes the value of {{setLargestFragment}} immediately after the test sets 
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test 
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can 
> see that stress-new-test failed 5 times with this exact failure before being 
> merged to develop:
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
>  (x2)
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547194#comment-17547194
 ] 

Geode Integration commented on GEODE-10361:
---

Seen in [windows-core-integration-test-openjdk11 
#382|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/382]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-results/integrationTest/1654211594/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-artifacts/1654211594/windows-coreintegrationtestfiles-openjdk11-1.16.0-build.0304.tgz].

> 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: needsTriage
>
> {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-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException

2022-06-03 Thread Alexander Murmann (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Murmann updated GEODE-10361:
--
Labels: needsTriage  (was: )

> 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
>Reporter: Kirk Lund
>Priority: Major
>  Labels: needsTriage
>
> {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-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-10361:
--
Affects Version/s: 1.14.0
   1.13.0
   1.15.0

> 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: needsTriage
>
> {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] [Created] (GEODE-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException

2022-06-03 Thread Kirk Lund (Jira)
Kirk Lund created GEODE-10361:
-

 Summary: 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
Reporter: Kirk Lund


{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] [Commented] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547141#comment-17547141
 ] 

Geode Integration commented on GEODE-1957:
--

Seen in [windows-core-integration-test-openjdk8 
#390|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/390]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0310/test-results/integrationTest/1654280042/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0310/test-artifacts/1654280042/windows-coreintegrationtestfiles-openjdk8-1.16.0-build.0310.tgz].

> CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
> 
>
> Key: GEODE-1957
> URL: https://issues.apache.org/jira/browse/GEODE-1957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Bruce J Schuchardt
>Priority: Minor
>  Labels: ci, flaky
>
> 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] [Commented] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547111#comment-17547111
 ] 

Geode Integration commented on GEODE-10360:
---

Seen on support/1.15 in [distributed-test-openjdk17 
#32|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/distributed-test-openjdk17/builds/32]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1303/test-results/distributedTest/1654220629/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1303/test-artifacts/1654220629/distributedtestfiles-openjdk17-1.15.0-build.1303.tgz].

> 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
>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 
> 

[jira] [Commented] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547109#comment-17547109
 ] 

Geode Integration commented on GEODE-10360:
---

Seen on support/1.15 in [distributed-test-openjdk17 
#34|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/distributed-test-openjdk17/builds/34]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1307/test-results/distributedTest/1654286230/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.1307/test-artifacts/1654286230/distributedtestfiles-openjdk17-1.15.0-build.1307.tgz].

> 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
>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 
> 

[jira] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-10360:
--
Affects Version/s: 1.14.0
   1.13.0
   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
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>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] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund updated GEODE-10360:
--
Component/s: wan

> 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
>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 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
>   

[jira] [Created] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Kirk Lund (Jira)
Kirk Lund created GEODE-10360:
-

 Summary: 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
Reporter: Kirk Lund


{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 
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at 
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
at 
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
at 
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
at 

[jira] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain

2022-06-03 Thread Alexander Murmann (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Murmann updated GEODE-10360:
--
Labels: needsTriage  (was: )

> 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
>Reporter: Kirk Lund
>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 
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at 
> 

[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547078#comment-17547078
 ] 

Geode Integration commented on GEODE-6504:
--

Seen in [windows-core-integration-test-openjdk8 
#386|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/386]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0305/test-results/integrationTest/1654217268/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0305/test-artifacts/1654217268/windows-coreintegrationtestfiles-openjdk8-1.16.0-build.0305.tgz].

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Reopened] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion

2022-06-03 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reopened GEODE-1957:
--

This is a real failure and still fails.

> CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
> 
>
> Key: GEODE-1957
> URL: https://issues.apache.org/jira/browse/GEODE-1957
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Bruce J Schuchardt
>Priority: Minor
>  Labels: ci, flaky
>
> 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] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547032#comment-17547032
 ] 

Geode Integration commented on GEODE-6504:
--

Seen in [windows-core-integration-test-openjdk8 
#384|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/384]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-results/integrationTest/1654211074/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-artifacts/1654211074/windows-coreintegrationtestfiles-openjdk8-1.16.0-build.0304.tgz].

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547031#comment-17547031
 ] 

Geode Integration commented on GEODE-6504:
--

Seen in [windows-core-integration-test-openjdk11 
#381|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/381]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0303/test-results/integrationTest/1654205736/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0303/test-artifacts/1654205736/windows-coreintegrationtestfiles-openjdk11-1.16.0-build.0303.tgz].

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547033#comment-17547033
 ] 

Geode Integration commented on GEODE-6504:
--

Seen in [windows-core-integration-test-openjdk11 
#382|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk11/builds/382]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-results/integrationTest/1654211594/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0304/test-artifacts/1654211594/windows-coreintegrationtestfiles-openjdk11-1.16.0-build.0304.tgz].

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-9089) Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants Fail

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547030#comment-17547030
 ] 

Geode Integration commented on GEODE-9089:
--

Seen on support/1.14 in [distributed-test-openjdk8 
#69|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/distributed-test-openjdk8/builds/69]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0976/test-results/distributedTest/1654286551/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0976/test-artifacts/1654286551/distributedtestfiles-openjdk8-1.14.5-build.0976.tgz].

> Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants 
> Fail
> -
>
> Key: GEODE-9089
> URL: https://issues.apache.org/jira/browse/GEODE-9089
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
>
> Two failures in this CI run: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/106:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest > 
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$151/1201663250.run
>  in VM 2 running on Host d2642cb6ec08 with 8 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.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:757)
> Caused by:
> 00, 899000, 665100, 587000, 518100, 721000, 623100, 551000, 592000, 182100, 
> 779100, 164100, 5104300, 5326300, 297000, 31100, 843000, 910100, 992000, 
> 456100, 190100, 982100, 5517300, 815000, 5411200, 1093000, 657100, 870100, 
> 5210300, 176100, 5065200, 294100, 5521300, 1034000, 570100, 5257200, 827000, 
> 5535200, 77100, 862000, 5419300, 255100, 681000, 348100, 5423200, 5194300, 
> 5416300, 5554200, 5392300, 711000, 857100, 320100, 5449200, 5348300, 5004200, 
> 426100, 111, 5487200, 787000, 884000, 5216200, 5560200, 580100, 861000, 
> 425000, 799100, 5553200, 972100, 5114200, 271000, 5000200, 243000, 172100, 
> 5561200, 262000, 1091100, 477100, 75, 109000, 5431300, 980100, 5237300, 
> 5308300, 5150200, 689000, 207000, 446100, 805100, 5111200, 9000, 00, 
> 5534300, 536100, 5062300, 1082000, 5397200, 798100, 5308200, 553000, 5374300, 
> 703000, 160100, 5560300, 38100, 4100, 678100, 1113100, 973000, 5558300, 
> 5175200, 5188200, 212100, 1007000, 1104000, 467100, 5540200, 809000, 810100, 
> 1106100, 1077100, 69100, 5143200, 776100, 5396200, 113100, 181000, 1094100, 
> 883100, 542100, 5031200, 147100, 481000, 353000, 1050100, 219100, 4000, 
> 576000, 393000, 248100, 5508200, 1012000, 380100, 5166300, 894100, 5398200, 
> 510100, 798000, 5066200, 5189200, 39, 832000, 5377200, 5022300, 311100, 
> 1017100, 383100, 5401200, 266000, 966100, 231000, 5382300, 778000, 276100, 
> 5320300, 529100, 496100, 5256200, 860100, 5360300, 1055100, 5250200, 609100, 
> 553100, 5259300, 5089300, 43, 5565200, 579100, 1065000, 424000, 622100, 
> 157000, 847100, 80100, 5460200, 5124300, 101000, 898100, 5292300, 482100, 
> 5553300, 1074100, 5499300, 554000, 5352200, 5039300, 2000, 667000, 376000, 
> 5143300, 753100, 466000, 5064300, 5006200, 5174200, 744100, 937000, 5145200, 
> 71100, 351100, 5289200, 206100, 805000, 5493200, 431000, 378100, 333100, 
> 5118200, 103100, 462000, 5527200, 5255200, 5033200, 56100, 521100, 8100, 
> 300, 42000, 331100, 5439200, 68, 801100, 65100, 5207300, 479000, 
> 792100, 5004300, 5171300, 318000, 681100, 619100, 955100, 903000, 72000, 
> 5292200, 1044000, 1023100, 323000, 5353300, 558000, 544100, 265000, 5018200, 
> 5340300, 751100, 607000, 582000, 465100, 253100, 935100, 174100, 5043300, 
> 537100, 178000, 1127100, 88100, 661100, 5402200, 3, 958100, 49000, 96100, 
> 979000, 5081300, 5075300, 5206300, 84000, 5154200, 1057100, 5409300, 62000, 
> 506000, 1107100, 5022200, 921000, 448100, 1004100, 427100, 829000, 1107000, 
> 244000, 414000, 74100, 409000, 833100, 77, 51000, 5113300, 908100, 
> 5312300, 5263300, 5148300, 138100, 336100, 1081000, 5365300, 151000, 165000, 
> 759000, 752000, 19, 5460300, 685000, 298100, 566100, 877100, 46, 
> 5108300, 377100, 71, 750100, 95100, 228100, 5116300, 522100, 5110200, 
> 45, 64, 5086200, 683000, 348000, 305000, 797100, 18, 636000, 
> 5494300, 634100, 

[jira] [Commented] (GEODE-8589) make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test deterministic

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17547029#comment-17547029
 ] 

Geode Integration commented on GEODE-8589:
--

Seen in [integration-test-openjdk11 
#395|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk11/builds/395]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0310/test-results/integrationTest/1654277786/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0310/test-artifacts/1654277786/integrationtestfiles-openjdk11-1.16.0-build.0310.tgz].

> make locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted test 
> deterministic
> ---
>
> Key: GEODE-8589
> URL: https://issues.apache.org/jira/browse/GEODE-8589
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Bill Burcham
>Priority: Major
>  Labels: membership, pull-request-available
>
> A recent commit added a new test: 
> {{MembershipIntegrationTest.locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}
> That's a good test. But it would be better if it ran faster and was less 
> susceptible to timing issues. The problem is that the logic we are trying to 
> test, {{GMSJoinLeave.leave()}} uses {{System.currentTimeMillis()}} to get the 
> current time and it uses {{Thread.sleep()}} to sleep:
> {code:java}
> long now = System.currentTimeMillis();
> ...
> if (state.joinedMembersContacted <= 0 && ((now >= 
> locatorGiveUpTime &&
> tries >= minimumRetriesBeforeBecomingCoordinator) ||
> state.locatorsContacted >= locators.size())) {
> ...
> if (System.currentTimeMillis() > giveupTime) {
>   break;
> }
> ...
>   Thread.sleep(retrySleep);
> ...
>   giveupTime = System.currentTimeMillis() + timeout;
> ...
>   if (!this.isJoined) {
> logger.debug("giving up attempting to join the distributed system 
> after "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> ...
>   if (!this.isJoined && state.hasContactedAJoinedLocator) {
> throw new MemberStartupException("Unable to join the distributed 
> system in "
> + (System.currentTimeMillis() - startTime) + "ms");
>   }
> {code}
> The opportunity is to _inject_ objects that handle these two functions (time 
> keeping and sleeping). This will enable us to artifically control these in 
> our test! Sleeping doesn't have to take any time at all. And we can make time 
> pass as quickly as we want to.
> For an example of how this can be done, see [PR 
> #5422|https://github.com/apache/geode/pull/5422] for GEODE-6950.
> This particular test 
> ({{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}}) is a 
> little bit more involved than that one in that more objects are involved. In 
> addition to {{GMSJoinLeave}}, other classes involved in the test also need 
> current time and need to sleep.
> When this ticket is complete:
> * functional interfaces {{MillisecondProvider}} and {{Sleeper}}, currently 
> defined inside {{PrimaryHandler}} will be moved higher in the (internal) 
> hierarchy for use by other membership classes
> * {{GMSJoinLeave}} will take a {{MillisecondProvider}} and {{Sleeper}} in its 
> constructor and will delegate to those instead of calling 
> {{System.currentTimeMillis()}} and {{Thread.sleep()}} directly
> * TBD other classes may require injection of {{MillisecondProvider}} and 
> {{Sleeper}}
> * TBD other changes may be necessary in cases where collaborating classes 
> currently spin up threads or synchronize between threads e.g. calling 
> {{wait()}}
> * {{locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()}} will no 
> longer employ {{Thread.sleep()}} nor will it call 
> {{CompletableFuture.get(long timeout, TimeUnit unit)}}—instead it will 
> operate deterministically (ideally in the same thread but not necessarily) 
> with respect to the unit under test.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Created] (GEODE-10359) add a performance test for the ThreadMonitor feature

2022-06-03 Thread Darrel Schneider (Jira)
Darrel Schneider created GEODE-10359:


 Summary: add a performance test for the ThreadMonitor feature
 Key: GEODE-10359
 URL: https://issues.apache.org/jira/browse/GEODE-10359
 Project: Geode
  Issue Type: Test
  Components: core
Reporter: Darrel Schneider


GEODE-8977 found that the thread monitor can impact performance of other 
healthy threads on a server.
We should have a JMH benchmark that measures the impact of the thread monitor 
on healthy threads. The test would have some number of threads that don't need 
to be doing anything (i.e. they can be stuck waiting for something). It should 
keep calling ThreadsMonitoringProcess.getThreadInfoMap at a high frequency. 
Meanwhile is should have a number of healthy threads that are doing repeated 
operations. The goal would be for the thread monitor to have minimal impact on 
the throughput of the healthy threads. The test could also see what the impact 
is if showLocks and/or batchCalls is true (these are getThreadInfoMap 
parameters).



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10352) Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode documentation

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546693#comment-17546693
 ] 

ASF subversion and git services commented on GEODE-10352:
-

Commit 728467cfd73bfc74020f9e2d7de8780231943a94 in geode's branch 
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=728467cfd7 ]

GEODE-10352: Update Ruby version in Geode doc preview tool (#7753)

The script to preview the documentation of Geode (./preview-user-guide.sh)
is not working anymore.

The following error appears while running it (unless you have a previously 
downloaded
geodedocs/temp docker image in your local docker repo):

ERROR: Error installing elasticsearch:
The last version of faraday (>= 0) to support your Ruby & RubyGems was 1.10.0. 
Try installing it with `gem install faraday -v 1.10.0` and then running the 
current command again
faraday requires Ruby version >= 2.6. The current ruby version is 2.5.9.229.

That error prevents the preview script to work.

It is needed to update the docker image used to preview the documentation to 
use a Ruby version >= 2.6.
The versions of other gems also need to be updated after the
change of the Ruby version.

> Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode 
> documentation
> ---
>
> Key: GEODE-10352
> URL: https://issues.apache.org/jira/browse/GEODE-10352
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>  Labels: pull-request-available
>
> The script to preview the documentation of Geode (./preview-user-guide.sh) is 
> not working anymore.
> The following error appears while running it (unless you have a previously 
> downloaded geodedocs/temp docker image in your local docker repo):
> ERROR:  Error installing elasticsearch:
>   The last version of faraday (>= 0) to support your Ruby & RubyGems was 
> 1.10.0. Try installing it with `gem install faraday -v 1.10.0` and then 
> running the current command again
>   faraday requires Ruby version >= 2.6. The current ruby version is 
> 2.5.9.229.
> That error prevents the preview script to work.
> It is needed to update the docker image used to preview the documentation to 
> use a Ruby version >= 2.6



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread Max Hufnagel (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546537#comment-17546537
 ] 

Max Hufnagel commented on GEODE-10342:
--

We've updated the list of jar files:
 * antlr jar
 * classgraph jar
 * commons-beanutils jar
 * commons-codec jar
 * commons-collections jar
 * commons-io jar
 * commons-lang3 jar
 * commons-logging jar
 * commons-math3 jar
 * commons-modeler jar
 * commons-validator jar
 * fastutil jar
 * geo jar
 * geode-common jar
 * geode-connectors jar
 * geode-core jar
 * geode-cq jar
 * geode-gfsh jar
 * geode-http-service jar
 * geode-log4j jar
 * geode-logging jar
 * geode-lucene jar
 * geode-management jar
 * geode-membership jar
 * geode-memcached jar
 * geode-old-client-support jar
 * geode-protobuf jar
 * geode-protobuf-messages jar
 * geode-rebalancer jar
 * geode-redis jar
 * geode-serialization jar
 * geode-tcp-server jar
 * geode-unsafe jar
 * geode-wan jar
 * grumpy-core jar
 * HdrHistogram jar
 * HikariCP jar
 * httpclient jar
 * httpcore jar
 * istack-commons-runtime jar
 * jackson-annotations jar
 * jackson-core jar
 * jackson-databind jar
 * javax.activation jar
 * javax.activation-api jar
 * javax.mail-api jar
 * javax.resource-api jar
 * javax.servlet-api jar
 * javax.transaction-api jar
 * jaxb-api jar
 * jaxb-impl jar
 * jetty-http jar
 * jetty-io jar
 * jetty-security jar
 * jetty-server jar
 * jetty-servlet jar
 * jetty-util jar
 * jetty-util-ajax jar
 * jetty-webapp jar
 * jetty-xml jar
 * jgroups jar
 * jline jar
 * jna jar
 * jna-platform jar
 * jopt-simple jar
 * LatencyUtils jar
 * log4j-api jar
 * log4j-core jar
 * log4j-jcl jar
 * log4j-jul jar
 * log4j-slf4j-impl jar
 * lucene-analyzers-common jar
 * lucene-analyzers-phonetic jar
 * lucene-core jar
 * lucene-queries jar
 * lucene-queryparser jar
 * micrometer-core jar
 * mx4j jar
 * mx4j-remote jar
 * mx4j-tools jar
 * netty-all jar
 * protobuf-java jar
 * rmiio jar
 * shiro-cache jar
 * shiro-config-core jar
 * shiro-config-ogdl jar
 * shiro-core jar
 * shiro-crypto-cipher jar
 * shiro-crypto-core jar
 * shiro-crypto-hash jar
 * shiro-event jar
 * shiro-lang jar
 * slf4j-api jar
 * snappy jar
 * spring-core jar
 * spring-jcl jar
 * spring-shell jar
 * swagger-annotations jar

> 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
>
> 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: 

[jira] [Assigned] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread Max Hufnagel (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Max Hufnagel reassigned GEODE-10342:


Assignee: Max Hufnagel

> 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
>
> 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] [Updated] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers

2022-06-03 Thread Anilkumar Gingade (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anilkumar Gingade updated GEODE-8977:
-
Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available  (was: 
GeodeOperationAPI 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, 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-8977) Thread monitoring service should also show locked monitors and synchronizers

2022-06-03 Thread Anilkumar Gingade (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anilkumar Gingade updated GEODE-8977:
-
Affects Version/s: 1.15.0

> 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
>
>
> 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] [Reopened] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers

2022-06-03 Thread Darrel Schneider (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reopened GEODE-8977:
-

It turns out that asking the JVM for the lock info is expensive compared to 
only asking for the stack. And it also turns out that on at least jdk11 getting 
ThreadInfo requires a global safepoint which stops all other threads from 
running. Also doing a large number of threads at once instead of one at a time 
makes the "stop the world" last longer.
Since thread monitoring is on by default, and it may think threads are stuck 
that are actually just doing an operation that takes a long time, it is 
important for it to "stop the world" for as short a time as possible. Also, in 
jdk15 and later, asking for a single thread's info (instead of a batch of 
threads) does not do a "stop the world" but instead just stops the single 
thread that might be stuck.

> 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
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: GeodeOperationAPI, 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] [Commented] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546524#comment-17546524
 ] 

ASF subversion and git services commented on GEODE-10342:
-

Commit b20081a4c4b44fb55566ec060722860a731c409b in geode's branch 
refs/heads/support/1.15 from Max Hufnagel
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b20081a4c4 ]

GEODE-10342: Add current jars to HTTP Module for Tomcat instructions 1.15 
(#7768)



> 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
>Priority: Major
>  Labels: pull-request-available
>
> 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-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546523#comment-17546523
 ] 

ASF subversion and git services commented on GEODE-10342:
-

Commit bb4c7dc4392fe38f6206bffc36d60cd651cee906 in geode's branch 
refs/heads/support/1.14 from Max Hufnagel
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bb4c7dc439 ]

GEODE-10342: Add current jars to HTTP Module for Tomcat instructions 1.14 
(#7767)



> 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
>Priority: Major
>  Labels: pull-request-available
>
> 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-10356) [Refactor] Correct the comments regarding removing old entries during conflation

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546365#comment-17546365
 ] 

ASF subversion and git services commented on GEODE-10356:
-

Commit 968331758cff9c315bb95c7159ac1610aed9ad34 in geode's branch 
refs/heads/develop from Nabarun Nag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=968331758c ]

GEODE-10356: Corrected the comment (#7762)

* The previous comment on removeOldEntry mentioned that the old entry
was replaced
* This has been corrected to mention that the old entry is removed and
the new entry has been added to the region queue

> [Refactor] Correct the comments regarding removing old entries during 
> conflation
> 
>
> Key: GEODE-10356
> URL: https://issues.apache.org/jira/browse/GEODE-10356
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Affects Versions: 1.16.0
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
>  Labels: pull-request-available
>
> Change the comments on method removeOldEntry to say that the old entry is 
> removed rather than replaced.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Resolved] (GEODE-10356) [Refactor] Correct the comments regarding removing old entries during conflation

2022-06-03 Thread Nabarun Nag (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nabarun Nag resolved GEODE-10356.
-
Fix Version/s: 1.16.0
   Resolution: Fixed

> [Refactor] Correct the comments regarding removing old entries during 
> conflation
> 
>
> Key: GEODE-10356
> URL: https://issues.apache.org/jira/browse/GEODE-10356
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Affects Versions: 1.16.0
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Change the comments on method removeOldEntry to say that the old entry is 
> removed rather than replaced.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>

2022-06-03 Thread Geode Integration (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546359#comment-17546359
 ] 

Geode Integration commented on GEODE-10323:
---

Seen in [windows-unit-test-openjdk11 
#392|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/392]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0308/test-results/test/1654271712/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0308/test-artifacts/1654271712/windows-unittestfiles-openjdk11-1.16.0-build.0308.tgz].

> OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: 
> expected:<100> but was:<1048576>
> 
>
> Key: GEODE-10323
> URL: https://issues.apache.org/jira/browse/GEODE-10323
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>
> [Please see 1st comment on this ticket below the description for 
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing 
> intermittently due to commit a350ed2 which went in as 
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance 
> off-heap fragmentation visibility. 
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at 
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor 
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the 
> constructor which immediately gets scheduled to invoke 
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of 
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of 
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and 
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a 
> bad practice and should only be done via some sort of activation method such 
> as {{start()}} which can be invoked from the static factory method for 
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct 
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other 
> tests, is written with the assumption that no other thread or component can 
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test 
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219:  stats.setLargestFragment(100);
> 220:  assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because 
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and 
> changes the value of {{setLargestFragment}} immediately after the test sets 
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test 
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can 
> see that stress-new-test failed 5 times with this exact failure before being 
> merged to develop:
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
>  (x2)
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation

2022-06-03 Thread Jinmei Liao (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546059#comment-17546059
 ] 

Jinmei Liao commented on GEODE-10351:
-

A test issue, not a blocker

> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jinmei Liao
>Priority: Major
>  Labels: needsTriage, pull-request-available
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError: 
> Expecting actual throwable to be an instance of:
>   java.lang.IllegalStateException
> but was:
>   org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A 
> DiskAccessException has occurred while writing to the disk for region 
> /region3. The region will be closed., caused by 
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A 
> DiskAccessException has occurred while writing to the disk for region 
> /region3. The region will be closed.
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
>   at 
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Commented] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17546033#comment-17546033
 ] 

ASF subversion and git services commented on GEODE-10342:
-

Commit 300a1596aecd89aebd2c71615da584a2e0a8442c in geode's branch 
refs/heads/develop from Max Hufnagel
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=300a1596ae ]

GEODE-10342: Add current jars to HTTP Module for Tomcat instructions (#7745)



> 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
>Priority: Major
>  Labels: pull-request-available
>
> 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] [Updated] (GEODE-10342) Update the HTTP Module for Tomcat instructions to include current required jars

2022-06-03 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-10342:
---
Labels: pull-request-available  (was: )

> 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
>Priority: Major
>  Labels: pull-request-available
>
> 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] [Resolved] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.

2022-06-03 Thread Joris Melchior (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joris Melchior resolved GEODE-10301.

Fix Version/s: 1.16.0
   Resolution: Fixed

> 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] [Commented] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.

2022-06-03 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545999#comment-17545999
 ] 

ASF subversion and git services commented on GEODE-10301:
-

Commit e370d2fb6c9f5e4281146fe78a4840452f70ca9e in geode's branch 
refs/heads/develop from Joris Melchior
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e370d2fb6c ]

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


> 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
>
> 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-10349) Client connects to a new server socket should check its availability

2022-06-03 Thread Jacob Barrett (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17545889#comment-17545889
 ] 

Jacob Barrett commented on GEODE-10349:
---

Then lower the connection timeout. DO NOT use {{InetAddress.isReachable()}}. 
The method makes a best effort check for availability of the host, not a 
listening port on a host. It is likely to report false positives and negatives 
depending on the current state of the host or any firewalls between client and 
server.

> Client connects to a new server socket should check its availability 
> -
>
> Key: GEODE-10349
> URL: https://issues.apache.org/jira/browse/GEODE-10349
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: pull-request-available
>
> When client connects to a new server (or restarted server), it might 
> encounter SocketTimeoutException which could take 59 seconds. 
> To speed up, the idea is to check if the server address's is reachable with 
> smaller timeout. 
> If the server's address is not reachable, no need to block waiting for 59 
> seconds (DEFAULT_SOCKET_CONNECT_TIMEOUT). 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)