[jira] [Updated] (GEODE-9379) Implement ZREVRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9379: -- Labels: pull-request-available redis (was: redis) > Implement ZREVRANGEBYSCORE Command > -- > > Key: GEODE-9379 > URL: https://issues.apache.org/jira/browse/GEODE-9379 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, redis > > Implement the [ZREVRANGEBYSCORE|https://redis.io/commands/zrevrangebyscore] > command. > > Acceptance Criteria > The ZREVRANGEBYSCORE command has been implemented along with appropriate unit > tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. > The command has been tested using the redis-cli tool. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9304) Make RedisSortedSet's measurement of byes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9304. Fix Version/s: 1.15.0 Resolution: Fixed > Make RedisSortedSet's measurement of byes in use more accurate > -- > > Key: GEODE-9304 > URL: https://issues.apache.org/jira/browse/GEODE-9304 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The current calculation of bytes in use by RedisSortedSet is inaccurate, and > needs to be improved. Once a strategy for size calculation for classes using > Object2ObjectCustomHash and OrderStatisticsTree has been decided, it should > be implemented for this data type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9304) Make RedisSortedSet's measurement of byes in use more accurate
[ https://issues.apache.org/jira/browse/GEODE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385706#comment-17385706 ] ASF subversion and git services commented on GEODE-9304: Commit d615470200f23999d7cab28582984663d8c42d74 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d615470 ] GEODE-9304: Make RedisSortedSet measurement of bytes in use accurate (#6699) - Add accurate size calulation to RedisSortedSet - Make OrderSatisticsSet implement Sizeable - Add size tracking to OrderStatisticsTree - Modify how SizeableObject2ObjectOpenCustomHashMapWithCursor calculates the size of elements to support elements implementing Siazeable - Make AbstractOrderedSetEntry implement Sizeable - Add size calculation to OrderedSetEntry - Introduce SizeableObjectSizer to efficiently get size in bytes of objects implementing Sizeable - Use SizeableObjectSizer internally in SizeableObject2ObjectOpenCustomHashMapWithCursor and SizeableObjectOpenCustomHashSet - Use Double comparison rather than byte array representing double comparison when both are available - Add unit tests for all new behaviour - Add memory overhead integration and acceptance tests for sorted sets Authored-by: Donal Evans > Make RedisSortedSet's measurement of byes in use more accurate > -- > > Key: GEODE-9304 > URL: https://issues.apache.org/jira/browse/GEODE-9304 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Ray Ingles >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The current calculation of bytes in use by RedisSortedSet is inaccurate, and > needs to be improved. Once a strategy for size calculation for classes using > Object2ObjectCustomHash and OrderStatisticsTree has been decided, it should > be implemented for this data type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9388) Implement ZRANGEBYLEX Command
[ https://issues.apache.org/jira/browse/GEODE-9388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9388: -- Labels: pull-request-available redis (was: redis) > Implement ZRANGEBYLEX Command > - > > Key: GEODE-9388 > URL: https://issues.apache.org/jira/browse/GEODE-9388 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > > Implement the [ZRANGEBYLEX|https://redis.io/commands/zrangebylex] command > without the LIMIT option. > +Acceptance Criteria+ > The ZRANGEBYLEX command has been implemented along with appropriate unit > tests. > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9365) HARegionQueue over throttles when multiple threads attempt concurrent adds
[ https://issues.apache.org/jira/browse/GEODE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385711#comment-17385711 ] Darrel Schneider commented on GEODE-9365: - Consider finding a way to optimize checkQueueSizeConstraint for the normal case of the queue not being full. I'm a bit concerned with the normal case now always making a system call to figure out the current time. What if we made "putPermits" an AtomicInteger that checkQueueSizeConstraint first calls (without any sync) putPermits.decrementAndGet on. If it returns a value < 0 then it drops into the permitMon code and can adjust the wait time depending on elapsed time. But if it is >= 0 then it is done and has not done any syncs or time calls. Keep in mind that all reconcilePutPermits does is make the putPermits atomic bigger. It will never make it smaller and it just returns the current value of putPermits. Currently checkQueueSizeConstraint decs putPermits at the end for the item it will be adding but I don't see anything wrong with it doing it at the start since it will be atomic and all other changes are done in checkQueueSizeConstraint while synced on permitMon. The only code that ever increases putPermits is reconcilePutPermits and this is done lazily once putPermits is < 0. Having all the threads concurrently calling checkQueueSizeConstraint do an atomic dec seems much better than them doing a sync on putGuard. > HARegionQueue over throttles when multiple threads attempt concurrent adds > -- > > Key: GEODE-9365 > URL: https://issues.apache.org/jira/browse/GEODE-9365 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Darrel Schneider >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > > HARegionQueue.checkQueueSizeConstraint has some code that implements a > "throttle" on adds to a queue that is full. It is supposed to wait > "eventEnqueueWaitTime" before doing an add. But because this code does two > syncs (putGuard and permitMon) and only waits on one of them, it holds the > other sync for the duration of this threads throttle. Any other concurrent > thread trying to add to the queue gets stuck on the putGuard sync that is > held by the first thread that is doing the timed wait. So it ends up waiting > "eventEnqueueWaitTime" to acquire the first sync and then ends up waiting > again "eventEnqueueWaitTime" when it does its own timed wait. If you have 10 > concurrent threads trying to add one of them will end up waiting 10 * > "eventEnqueueWaitTime". > A couple ideas of how to fix this. Get rid of the putGuard and just use > permitMon. Then as soon as the first thread goes into its timed wait another > thread is allowed to sync on permitMon. But if this is done then we need to > think carefully about the code inside this sync block since it can not be > executed while one or more other threads are waiting in permitMon. > The other solution would be to compute the elapsed time it took to get into > the first sync and subtract that from the time we wait on permitMon. This > seems like a simple solution but does introduce at least one call of get time > (the second call is only needed if the queue is full). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9426) Update docs for HTTP Session Management
[ https://issues.apache.org/jira/browse/GEODE-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385787#comment-17385787 ] ASF subversion and git services commented on GEODE-9426: Commit 54853e0c51d9ef6fc5f96d8753dc298d7cc1f9b9 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=54853e0 ] GEODE-9426: Update docs for HTTP session management (#6703) (#6706) (cherry picked from commit 4618604670ed2f4517653f10294b746c6d0c1e82) > Update docs for HTTP Session Management > --- > > Key: GEODE-9426 > URL: https://issues.apache.org/jira/browse/GEODE-9426 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.13.4, 1.15.0 > > > [From a community member] I suspect this affects many older versions ... but > I wanted to document what I saw as I attempted to follow the docs: > This page has incorrect jar: > [https://geode.apache.org/docs/guide/113/tools_modules/http_session_mgmt/tomcat_installing_the_module.html] > > {{"geode-commons jar" should be "geode-common jar" ... no "s"}} > Also missing geode tcp server jar (geode-tcp-server) > And is missing this step (copied here from geode-examples): > {nofomat} > $ cp $CATALINA_HOME/bin/tomcat-juli.jar $CATALINA_HOME/lib/ > App would not start with this in context.xml ... it was not there already ... > and when I added it, startup failed. > Suggest working through both the geode-examples AND the official > documentation to verify correctness. [Example treated separately - see > GEODE-9430] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9426) Update docs for HTTP Session Management
[ https://issues.apache.org/jira/browse/GEODE-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-9426. Fix Version/s: 1.14.0 Resolution: Fixed > Update docs for HTTP Session Management > --- > > Key: GEODE-9426 > URL: https://issues.apache.org/jira/browse/GEODE-9426 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.13.4, 1.14.0, 1.15.0 > > > [From a community member] I suspect this affects many older versions ... but > I wanted to document what I saw as I attempted to follow the docs: > This page has incorrect jar: > [https://geode.apache.org/docs/guide/113/tools_modules/http_session_mgmt/tomcat_installing_the_module.html] > > {{"geode-commons jar" should be "geode-common jar" ... no "s"}} > Also missing geode tcp server jar (geode-tcp-server) > And is missing this step (copied here from geode-examples): > {nofomat} > $ cp $CATALINA_HOME/bin/tomcat-juli.jar $CATALINA_HOME/lib/ > App would not start with this in context.xml ... it was not there already ... > and when I added it, startup failed. > Suggest working through both the geode-examples AND the official > documentation to verify correctness. [Example treated separately - see > GEODE-9430] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9448) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException
Kamilla Aslami created GEODE-9448: - Summary: CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException Key: GEODE-9448 URL: https://issues.apache.org/jira/browse/GEODE-9448 Project: Geode Issue Type: Bug Components: jmx, tests Reporter: Kamilla Aslami This failure is similar to GEODE-8191 but the stack trace looks a bit different: {noformat} org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but was:<[375]0> within 5 minutes. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) at org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108) Caused by: java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask.get(FutureTask.java:204) at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) at org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102) ... 5 more{noformat} I noticed that in the last failure reported on GEODE-8191 ([run #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/26]), the version of Awaitility was 4.0.3. In this failure, the version is 4.1.0, so this might be the reason why the stack traces are different. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9448) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException
[ https://issues.apache.org/jira/browse/GEODE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385788#comment-17385788 ] Geode Integration commented on GEODE-9448: -- Seen in [distributed-test-openjdk11 #95|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/95] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0379/test-results/distributedTest/1626986847/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0379/test-artifacts/1626986847/distributedtestfiles-openjdk11-1.15.0-build.0379.tgz]. > CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with > ConditionTimeoutException caused by TimeoutException > > > Key: GEODE-9448 > URL: https://issues.apache.org/jira/browse/GEODE-9448 > Project: Geode > Issue Type: Bug > Components: jmx, tests >Reporter: Kamilla Aslami >Priority: Major > > This failure is similar to GEODE-8191 but the stack trace looks a bit > different: > {noformat} > org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but > was:<[375]0> within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) > at > org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:204) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102) > ... 5 more{noformat} > I noticed that in the last failure reported on GEODE-8191 ([run > #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/26]), > the version of Awaitility was 4.0.3. In this failure, the version is 4.1.0, > so this might be the reason why the stack traces are different. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9448) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with ConditionTimeoutException caused by TimeoutException
[ https://issues.apache.org/jira/browse/GEODE-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385789#comment-17385789 ] Kamilla Aslami commented on GEODE-9448: --- [~mivanac], could you please take a look at this failure? It might be a duplicate of GEODE-8191 > CI Failure: MemberMXBeanDistributedTest.testBucketCount failed with > ConditionTimeoutException caused by TimeoutException > > > Key: GEODE-9448 > URL: https://issues.apache.org/jira/browse/GEODE-9448 > Project: Geode > Issue Type: Bug > Components: jmx, tests >Reporter: Kamilla Aslami >Priority: Major > > This failure is similar to GEODE-8191 but the stack trace looks a bit > different: > {noformat} > org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but > was:<[375]0> within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) > at > org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:204) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:102) > ... 5 more{noformat} > I noticed that in the last failure reported on GEODE-8191 ([run > #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/26]), > the version of Awaitility was 4.0.3. In this failure, the version is 4.1.0, > so this might be the reason why the stack traces are different. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[ https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385790#comment-17385790 ] Geode Integration commented on GEODE-9302: -- Seen in [benchmark-base #92|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/92]. > Benchmark instability in PartitionedPutStringBenchmark > -- > > Key: GEODE-9302 > URL: https://issues.apache.org/jira/browse/GEODE-9302 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Priority: Major > > A benchmark failure due to the recently-introduced > PartitionedPutStringBenchmark was observed: > {noformat} > This is ITERATION 1 of benchmarking against baseline. > P2pPartitionedGetBenchmark avg ops/sec > Baseline:853001.60 Test:867151.67 Difference: +1.7% > avg latency > Baseline:842007.55 Test:828545.06 Difference: -1.6% > P2pPartitionedPutBenchmark avg ops/sec > Baseline:128283.47 Test:126510.92 Difference: -1.4% > avg latency > Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3% > P2pPartitionedPutBytesBenchmark avg ops/sec > Baseline:175658.08 Test:174865.97 Difference: -0.5% > avg latency > Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0% >PartitionedFunctionExecutionBenchmark avg ops/sec > Baseline:254788.26 Test:268132.99 Difference: +5.2% > avg latency > Baseline:846158.41 Test:804199.42 Difference: -5.0% > PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec > Baseline:278669.87 Test:281504.58 Difference: +1.0% > avg latency > Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0% > PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec > Baseline:372204.82 Test:348815.81 Difference: -6.3% > avg latency > Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8% > PartitionedGetBenchmark avg ops/sec > Baseline:823740.09 Test:819044.99 Difference: -0.6% > avg latency > Baseline:872172.75 Test:877580.02 Difference: +0.6% > PartitionedGetLongBenchmark avg ops/sec > Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2% > avg latency > Baseline:685757.55 Test:687005.43 Difference: +0.2% >PartitionedGetStringBenchmark avg ops/sec > Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0% > avg latency > Baseline:680031.44 Test:687045.15 Difference: +1.0% > PartitionedIndexedQueryBenchmark avg ops/sec > Baseline: 31596.35 Test: 31653.48 Difference: +0.2% > avg latency > Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0% > PartitionedNonIndexedQueryBenchmark avg ops/sec > Baseline:95.78 Test: 100.35 Difference: +4.8% > avg latency > Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5% > PartitionedPutAllBenchmark avg ops/sec > Baseline: 8675.75 Test: 8628.10 Difference: -0.5% > avg latency > Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5% > PartitionedPutAllLongBenchmark avg ops/sec > Baseline: 1382.38 Test: 1380.50 Difference: -0.1% > avg latency > Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1% > PartitionedPutBenchmark avg ops/sec > Baseline:491790.40 Test:479926.75 Difference: -2.4% > avg latency > Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4% >
[jira] [Updated] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8728: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385834#comment-17385834 ] Kamilla Aslami commented on GEODE-9340: --- Re-opening this ticket because of the recent failure in [benchmark-base #92|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/92]. I compared the results of runs #90-#93, and also re-ran the test multiple times against the commit from run #92, here are the results: run #93 (commit 198f66489d842994abbcbabd621c3ed6f4d8c730): {noformat} average ops/second Baseline: 378109.51 Test: 396779.27 Difference: +4.9% average latency Baseline: 1902090.07 Test: 1812617.89 Difference: -4.7% {noformat} run #92 (commit 198f66489d842994abbcbabd621c3ed6f4d8c730): {noformat} average ops/second Baseline: 402166.74 Test: 372212.52 Difference: -7.4% average latency Baseline: 1788323.03 Test: 1928963.36 Difference: +7.9% average ops/second Baseline: 406847.58 Test: 381640.51 Difference: -6.2% average latency Baseline: 1766726.63 Test: 1885246.76 Difference: +6.7% average ops/second Baseline: 401843.61 Test: 375389.09 Difference: -6.6% average latency Baseline: 1789773.35 Test: 1914011.63 Difference: +6.9% average ops/second Baseline: 401843.61 Test: 375389.09 Difference: -6.6% average latency Baseline: 1789773.35 Test: 1914011.63 Difference: +6.9% {noformat} run #91 (commit d77cb31c85112a1ffadb6d2a152b4627216ccc97): {noformat} average ops/second Baseline: 407387.94 Test: 381908.21 Difference: -6.3% average latency Baseline: 1764300.31 Test: 1876359.31 Difference: +6.4% average ops/second Baseline: 400480.51 Test: 375298.65 Difference: -6.3% average latency Baseline: 1794889.41 Test: 1916963.34 Difference: +6.8% average ops/second Baseline: 411374.65 Test: 389488.66 Difference: -5.3% average latency Baseline: 1749978.64 Test: 1846938.84 Difference: +5.5% average ops/second Baseline: 403485.67 Test: 392747.92 Difference: -2.7% average latency Baseline: 1780935.98 Test: 1829789.87 Difference: +2.7% {noformat} run #90 (commit 6890221ddba6c60c80796f581dab164f4043b65b): {noformat} average ops/second Baseline: 432650.78 Test: 436356.45 Difference: +0.9% average latency Baseline: 1659669.35 Test: 1646870.95 Difference: -0.8% {noformat} My runs against the commit from run #92 (198f66489d842994abbcbabd621c3ed6f4d8c730): {noformat} average ops/second Baseline: 470750.22 Test: 456675.50 Difference: -3.0% average latency Baseline: 1526914.73 Test: 1575478.61 Difference: +3.2% average ops/second Baseline: 476320.68 Test: 447205.19 Difference: -6.1% average latency Baseline: 1509780.07 Test: 1607165.71 Difference: +6.5% average ops/second Baseline: 470806.38 Test: 449991.12 Difference: -4.4% average latency Baseline: 1528579.11 Test: 1598805.03 Difference: +4.6% average ops/second Baseline: 469154.56 Test: 464860.14 Difference: -0.9% average latency Baseline: 1532256.37 Test: 1547035.80 Difference: +1.0% {noformat} It looks like there is some instability in this benchmark. Also, I'm not sure why run #91 didn't fail - 3 out of 4 runs had results >5% worse than baseline. > Benchmark instability in PartitionedPutLongBenchmark > > > Key: GEODE-9340 > URL: https://issues.apache.org/jira/browse/GEODE-9340 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Sarah Abbey >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.13.3, 1.13.4, 1.14.0, 1.15.0 > > > PartitionedPutLongBenchmark failed in CI > (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6): > {code:java} > This is ITERATION 1 of benchmarking against baseline. > P2pPartitionedGetBenchmark avg ops/sec > Baseline:825011.38 Test:835847.67 Difference: +1.3% > avg latency > Baseline:871392.31 Test:859444.66 Difference: -1.4% > P2pPartitionedPutBenchmark avg ops/sec > Baseline:123838.43 Test:122686.30 Difference: -0.9% > avg latency > Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7% > P2pPartitionedPutBytesBenchmark avg ops/sec > Baseline:174887.77 Test:171040.93 Difference: -2.2% > avg latency > Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2% > PartitionedFunctionExecutionBenchmark avg ops/sec > Baseline:248635.36 Test:261498.94 Difference: +5.2%
[jira] [Reopened] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami reopened GEODE-9340: --- > Benchmark instability in PartitionedPutLongBenchmark > > > Key: GEODE-9340 > URL: https://issues.apache.org/jira/browse/GEODE-9340 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Sarah Abbey >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.13.3, 1.13.4, 1.14.0, 1.15.0 > > > PartitionedPutLongBenchmark failed in CI > (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6): > {code:java} > This is ITERATION 1 of benchmarking against baseline. > P2pPartitionedGetBenchmark avg ops/sec > Baseline:825011.38 Test:835847.67 Difference: +1.3% > avg latency > Baseline:871392.31 Test:859444.66 Difference: -1.4% > P2pPartitionedPutBenchmark avg ops/sec > Baseline:123838.43 Test:122686.30 Difference: -0.9% > avg latency > Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7% > P2pPartitionedPutBytesBenchmark avg ops/sec > Baseline:174887.77 Test:171040.93 Difference: -2.2% > avg latency > Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2% > PartitionedFunctionExecutionBenchmark avg ops/sec > Baseline:248635.36 Test:261498.94 Difference: +5.2% > avg latency > Baseline:867122.63 Test:824550.34 Difference: -4.9% > PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec > Baseline:280071.19 Test:275305.31 Difference: -1.7% > avg latency > Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7% > PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec > Baseline:301416.23 Test:304317.30 Difference: +1.0% > avg latency > Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0% > PartitionedGetBenchmark avg ops/sec > Baseline:790800.52 Test:784514.74 Difference: -0.8% > avg latency > Baseline:908357.58 Test:915790.96 Difference: +0.8% > PartitionedGetLongBenchmark avg ops/sec > Baseline: 1020821.32 Test:996529.93 Difference: -2.4% > avg latency > Baseline:703761.09 Test:720744.36 Difference: +2.4% > PartitionedGetStringBenchmark avg ops/sec > Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8% > avg latency > Baseline:698009.55 Test:710765.29 Difference: +1.8% > PartitionedIndexedQueryBenchmark avg ops/sec > Baseline: 30868.78 Test: 31478.90 Difference: +2.0% > avg latency > Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1% > PartitionedNonIndexedQueryBenchmark avg ops/sec > Baseline:99.45 Test: 101.97 Difference: +2.5% > avg latency > Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5% > PartitionedPutAllBenchmark avg ops/sec > Baseline: 7921.61 Test: 7816.66 Difference: -1.3% > avg latency > Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3% > PartitionedPutAllLongBenchmark avg ops/sec > Baseline: 1379.53 Test: 1169.16 Difference: -15.2% > avg latency > Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7% > PartitionedPutBenchmark avg ops/sec > Baseline:474986.11 Test:467924.19 Difference: -1.5% > avg latency > Baseline: 1514276.31 Test: 1536263.99 Difference: +1.5% >
[jira] [Commented] (GEODE-9332) CI Failure: JmxServerReconnectDistributedTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash
[ https://issues.apache.org/jira/browse/GEODE-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385882#comment-17385882 ] Geode Integration commented on GEODE-9332: -- Seen on support/1.13 in [distributed-test-openjdk8 #15|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/15] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.3-build.0548/test-results/distributedTest/1623914604/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.3-build.0548/test-artifacts/1623914604/distributedtestfiles-openjdk8-1.13.3-build.0548.tgz]. > CI Failure: JmxServerReconnectDistributedTest > > serverMXBeansOnServerAreUnaffectedByLocatorCrash > > > Key: GEODE-9332 > URL: https://issues.apache.org/jira/browse/GEODE-9332 > Project: Geode > Issue Type: Test > Components: jmx, tests >Reporter: Owen Nichols >Priority: Major > > {noformat} > java.lang.AssertionError: [GemFire mxbeans on locator2] > Expecting HashSet: > [GemFire:type=Member,member=locator1, > > GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2, > GemFire:service=Region,name=/region,type=Member,member=server, > GemFire:service=Manager,type=Member,member=locator1, > GemFire:service=Locator,type=Member,member=locator2, > GemFire:type=Member,member=locator2, > GemFire:type=Member,member=server, > GemFire:service=FileUploader,type=Distributed, > > GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2, > GemFire:service=Manager,type=Member,member=locator2, > GemFire:service=Locator,type=Member,member=locator1, > GemFire:service=System,type=Distributed, > GemFire:service=AccessControl,type=Distributed, > > GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed, > GemFire:service=Region,name=/region,type=Distributed, > > GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1] > to contain: > [GemFire:type=Member,member=locator1, > GemFire:service=Locator,type=Member,member=locator1, > GemFire:service=Manager,type=Member,member=locator1, > > GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1, > > GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1] > but could not find the following element(s): > > [GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1] > at > org.apache.geode.management.JmxServerReconnectDistributedTest.lambda$null$7(JmxServerReconnectDistributedTest.java:203) > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-694) CI failure: ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover
[ https://issues.apache.org/jira/browse/GEODE-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385883#comment-17385883 ] Geode Integration commented on GEODE-694: - Seen on support/1.13 in [distributed-test-openjdk8 #23|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/23] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0560/test-results/distributedTest/1625653197/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0560/test-artifacts/1625653197/distributedtestfiles-openjdk8-1.13.4-build.0560.tgz]. > CI failure: > ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover > - > > Key: GEODE-694 > URL: https://issues.apache.org/jira/browse/GEODE-694 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.0.0-incubating >Reporter: Jens Deppe >Priority: Major > Labels: CI, Flaky > > https://builds.apache.org/job/Geode-nightly/313/testReport/junit/com.gemstone.gemfire.internal.cache.tier.sockets/ReliableMessagingDUnitTest/testPeriodicAckSendByClientPrimaryFailover/ > git rev ec9d16a3130e33ee53d837301dc35c3a8bf0e99d build #313 > {noformat} > Error Message > junit.framework.AssertionFailedError: Creation time 1450161450166 supposed to > be same as seo 1450161454951 > Stacktrace > junit.framework.AssertionFailedError: Creation time 1450161450166 supposed to > be same as seo 1450161454951 > at junit.framework.Assert.fail(Assert.java:57) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.TestCase.assertTrue(TestCase.java:192) > at > com.gemstone.gemfire.internal.cache.tier.sockets.ReliableMessagingDUnitTest.waitForClientAck(ReliableMessagingDUnitTest.java:150) > at > com.gemstone.gemfire.internal.cache.tier.sockets.ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover(ReliableMessagingDUnitTest.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at junit.framework.TestCase.runTest(TestCase.java:176) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java: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:49
[jira] [Commented] (GEODE-9071) CI Failure: PartitionedRegionCqQueryDUnitTest > testRemoveAllWithCQLocalDestroy
[ https://issues.apache.org/jira/browse/GEODE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385884#comment-17385884 ] Geode Integration commented on GEODE-9071: -- Seen on support/1.13 in [distributed-test-openjdk8 #25|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/25] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0562/test-results/distributedTest/1625797580/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0562/test-artifacts/1625797580/distributedtestfiles-openjdk8-1.13.4-build.0562.tgz]. > CI Failure: PartitionedRegionCqQueryDUnitTest > > testRemoveAllWithCQLocalDestroy > --- > > Key: GEODE-9071 > URL: https://issues.apache.org/jira/browse/GEODE-9071 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.3, 1.13.3, 1.14.0, 1.15.0 >Reporter: Jens Deppe >Priority: Major > Labels: caching-applications > > {noformat} > org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest > > testRemoveAllWithCQLocalDestroy FAILED > 10:10:22org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest$$Lambda$87/434016892.run > in VM 2 running on Host bb8c1d338b8b with 4 VMs > 10:10:22at > org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > 10:10:22at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > 10:10:22at > org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testRemoveAllWithCQLocalDestroy(PartitionedRegionCqQueryDUnitTest.java:243) > 10:10:22 > 10:10:22Caused by: > 10:10:22org.junit.ComparisonFailure: expected:<[999]> but was:<[645]> > 10:10:22at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > 10:10:22at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > 10:10:22at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > 10:10:22at > org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.lambda$testRemoveAllWithCQLocalDestroy$c93719d5$3(PartitionedRegionCqQueryDUnitTest.java:251) > {noformat} > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[ https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385886#comment-17385886 ] Geode Integration commented on GEODE-8634: -- Seen on support/1.13 in [distributed-test-openjdk8 #26|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/26] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0562/test-results/distributedTest/1625809793/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0562/test-artifacts/1625809793/distributedtestfiles-openjdk8-1.13.4-build.0562.tgz]. > CI failure: AsyncInvocationTimeoutDistributedTest. > get_callable_timeout_includesStackTraceAsCause > - > > Key: GEODE-8634 > URL: https://issues.apache.org/jira/browse/GEODE-8634 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.13.0, 1.14.0 >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24 > {noformat} > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest > > get_callable_timeout_includesStackTraceAsCause FAILED > java.lang.AssertionError: > Expecting message to be: > <"Stack trace for vm-0 thread-32"> > but was: > <"Stack trace for vm-0 thread-33"> > Throwable that failed the check: > org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0 > thread-33 > at sun.misc.Unsafe.park(Native Method) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown > Source) > at > org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123) > at > org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) > at sun.rmi.transport.Transport$1.run(Transport.java:200) > at sun.rmi.transport.Transport$1.run(Transport.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:196) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown > Source) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCau
[jira] [Commented] (GEODE-9280) CI Failure: ClientServerMiscBCDUnitTest > testSubscriptionWithMixedServersAndOldClientFeed[0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385888#comment-17385888 ] Geode Integration commented on GEODE-9280: -- Seen on support/1.13 in [upgrade-test-openjdk8 #29|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk8/builds/29] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0570/test-results/upgradeTest/1626860990/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0570/test-artifacts/1626860990/upgradetestfiles-openjdk8-1.13.4-build.0570.tgz]. > CI Failure: ClientServerMiscBCDUnitTest > > testSubscriptionWithMixedServersAndOldClientFeed[0] FAILED > > > Key: GEODE-9280 > URL: https://issues.apache.org/jira/browse/GEODE-9280 > Project: Geode > Issue Type: Test > Components: ci, client/server >Reporter: Jens Deppe >Priority: Major > > {noformat} > org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest > > testSubscriptionWithMixedServersAndOldClientFeed[0] FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 4 running > on Host ca88a5f241e5 with 5 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:435) > at > org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.doTestSubscriptionWithMixedServersAndPeerFeed(ClientServerMiscBCDUnitTest.java:249) > at > org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.testSubscriptionWithMixedServersAndOldClientFeed(ClientServerMiscBCDUnitTest.java:177) > Caused by: > java.util.NoSuchElementException > at > java.util.concurrent.ConcurrentHashMap$ValueIterator.next(ConcurrentHashMap.java:3436) > at > java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1044) > at > org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.lambda$doTestSubscriptionWithMixedServersAndPeerFeed$60ce2e92$7(ClientServerMiscBCDUnitTest.java:251) > {noformat} > {noformat} > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0244/test-results/upgradeTest/1621094517/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0244/test-artifacts/1621094517/upgradetestfiles-OpenJDK8-1.15.0-build.0244.tgz > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[ https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385887#comment-17385887 ] Geode Integration commented on GEODE-8634: -- Seen on support/1.13 in [distributed-test-openjdk8 #31|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/31] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0567/test-results/distributedTest/1626738622/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0567/test-artifacts/1626738622/distributedtestfiles-openjdk8-1.13.4-build.0567.tgz]. > CI failure: AsyncInvocationTimeoutDistributedTest. > get_callable_timeout_includesStackTraceAsCause > - > > Key: GEODE-8634 > URL: https://issues.apache.org/jira/browse/GEODE-8634 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.13.0, 1.14.0 >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24 > {noformat} > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest > > get_callable_timeout_includesStackTraceAsCause FAILED > java.lang.AssertionError: > Expecting message to be: > <"Stack trace for vm-0 thread-32"> > but was: > <"Stack trace for vm-0 thread-33"> > Throwable that failed the check: > org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0 > thread-33 > at sun.misc.Unsafe.park(Native Method) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown > Source) > at > org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123) > at > org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) > at sun.rmi.transport.Transport$1.run(Transport.java:200) > at sun.rmi.transport.Transport$1.run(Transport.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:196) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown > Source) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at > org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCau
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[ https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385889#comment-17385889 ] Geode Integration commented on GEODE-7710: -- Seen on support/1.13 in [distributed-test-openjdk11 #20|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/20] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0555/test-results/distributedTest/1624929113/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.4-build.0555/test-artifacts/1624929113/distributedtestfiles-openjdk11-1.13.4-build.0555.tgz]. > CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest > fails intermittently because one locator is missing the LockServiceMXBean > -- > > Key: GEODE-7710 > URL: https://issues.apache.org/jira/browse/GEODE-7710 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.13.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, flaky, pull-request-available > Time Spent: 5h > Remaining Estimate: 0h > > Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of > the locators missing the LockServiceMXBean for the cluster config service. > {noformat} > but could not find: > > <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]> > {noformat} > These test failures are caused by *GEODE-7739*. -- This message was sent by Atlassian Jira (v8.3.4#803005)