[jira] [Updated] (GEODE-9758) Provide an easy to configure process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9758: - Summary: Provide an easy to configure process-wide serialization filter for use on Java 8 (was: Provide an easy to configure a process-wide serialization filter for use on Java 8) > Provide an easy to configure process-wide serialization filter for use on > Java 8 > > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. > To configure a process-wide filter, specifiy > geode.enableGlobalSerialFilter=true and then configure > serializable-object-filter with any serializable domain objects provided by > the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-9758: - Description: Provide an easy way to configure a process-wide serialization filter for use on Java 8. When enabled, validate-serializable-objects should be enabled and the process-wide serialization filter should be configured to accept only JDK classes and Geode classes in addition to anything the user might specify with serializable-object-filter. To configure a process-wide filter, specifiy geode.enableGlobalSerialFilter=true and then configure serializable-object-filter with any serializable domain objects provided by the user. was:Provide an easy way to configure a process-wide serialization filter for use on Java 8. When enabled, validate-serializable-objects should be enabled and the process-wide serialization filter should be configured to accept only JDK classes and Geode classes in addition to anything the user might specify with serializable-object-filter. > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. > To configure a process-wide filter, specifiy > geode.enableGlobalSerialFilter=true and then configure > serializable-object-filter with any serializable domain objects provided by > the user. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602560#comment-17602560
]
Kirk Lund commented on GEODE-10415:
---
All of these issues should be resolvable by bumping dependencies.
* JGroups
[GHSA-rc7h-x6cq-988q|https://deps.dev/advisory/ghsa/GHSA-rc7h-x6cq-988q] aka
[CVE-2016-2141|https://nvd.nist.gov/vuln/detail/CVE-2016-2141] refers to
“Improper Input Validation in JGroups”
* Jetty [CVE-2022-2048|https://nvd.nist.gov/vuln/detail/CVE-2022-2048] refers
to “An invalid HTTP/2 request that can be used for Denial of Service”
* Shiro [CVE-2022-32532|https://nvd.nist.gov/vuln/detail/CVE-2022-32532] refers
to “RegexRequestMatcher misconfigured resulting in bypassing authorization”
* Spring [CVE-2016-127|https://nvd.nist.gov/vuln/detail/CVE-2016-127]
refers to “Potential RCE for Java deserialization of untrusted data” (sound
familiar?)
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Weijie Xu
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-10415:
-
Assignee: Kirk Lund
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Kirk Lund
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-9354) Refactor ArgumentRedactor and add tests for ssl-*store-password props
[
https://issues.apache.org/jira/browse/GEODE-9354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9354:
-
Description:
Refactor ArgumentRedactor to clean it up and make sure it's efficient.
Add test coverage for log statements containing:
{noformat}
-Dgemfire.ssl-truststore-password=
-Dgemfire.ssl-keystore-password=
{noformat}
---
Related to
[CVE-2021-34797|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34797]
in which logging is vulnerable to a log file redaction of sensitive information
flaw when using values that begin with characters other than letters or numbers
for passwords and security properties with the prefix "sysprop-",
"javax.net.ssl", or "security-". This issue is fixed by overhauling the log
file redaction in Apache Geode versions 1.12.5, 1.13.5, and 1.14.0.
Fixed in https://github.com/apache/geode/pull/6641.
Backported to:
* 1.14 in https://github.com/apache/geode/pull/6747
* 1.13 in https://github.com/apache/geode/pull/6749
* 1.12 in https://github.com/apache/geode/pull/6750
was:
Refactor ArgumentRedactor to clean it up and make sure it's efficient.
Add test coverage for log statements containing:
{noformat}
-Dgemfire.ssl-truststore-password=
-Dgemfire.ssl-keystore-password=
{noformat}
Related to
[CVE-2021-34797|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34797]
in which logging is vulnerable to a log file redaction of sensitive information
flaw when using values that begin with characters other than letters or numbers
for passwords and security properties with the prefix "sysprop-",
"javax.net.ssl", or "security-". This issue is fixed by overhauling the log
file redaction in Apache Geode versions 1.12.5, 1.13.5, and 1.14.0.
Fixed in https://github.com/apache/geode/pull/6641.
Backported to:
* 1.14 in https://github.com/apache/geode/pull/6747
* 1.13 in https://github.com/apache/geode/pull/6749
* 1.12 in https://github.com/apache/geode/pull/6750
> Refactor ArgumentRedactor and add tests for ssl-*store-password props
> -
>
> Key: GEODE-9354
> URL: https://issues.apache.org/jira/browse/GEODE-9354
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.4, 1.13.4
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.12.5, 1.13.5, 1.14.0, 1.15.0
>
>
> Refactor ArgumentRedactor to clean it up and make sure it's efficient.
> Add test coverage for log statements containing:
> {noformat}
> -Dgemfire.ssl-truststore-password=
> -Dgemfire.ssl-keystore-password=
> {noformat}
> ---
> Related to
> [CVE-2021-34797|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-34797]
> in which logging is vulnerable to a log file redaction of sensitive
> information flaw when using values that begin with characters other than
> letters or numbers for passwords and security properties with the prefix
> "sysprop-", "javax.net.ssl", or "security-". This issue is fixed by
> overhauling the log file redaction in Apache Geode versions 1.12.5, 1.13.5,
> and 1.14.0.
> Fixed in https://github.com/apache/geode/pull/6641.
> Backported to:
> * 1.14 in https://github.com/apache/geode/pull/6747
> * 1.13 in https://github.com/apache/geode/pull/6749
> * 1.12 in https://github.com/apache/geode/pull/6750
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10366) Using GfshRule default constructor leaves test directories around
[ https://issues.apache.org/jira/browse/GEODE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10366. --- Fix Version/s: 1.15.0 1.16.0 Resolution: Fixed > Using GfshRule default constructor leaves test directories around > - > > Key: GEODE-10366 > URL: https://issues.apache.org/jira/browse/GEODE-10366 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Using GfshRule default constructor leaves test directories around. It's > supposed to automatically delete the test directories after the test > completes. This is not a blocker for 1.15 but the fix should be merged to > develop and possibly support/1.15 unless it's frozen for release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552466#comment-17552466
]
Kirk Lund commented on GEODE-10374:
---
[~ukohlmeyer] Could you please attach the log file with the Geode log banner?
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, jdk17, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10366) Using GfshRule default constructor leaves test directories around
[ https://issues.apache.org/jira/browse/GEODE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-10366: - Assignee: Kirk Lund > Using GfshRule default constructor leaves test directories around > - > > Key: GEODE-10366 > URL: https://issues.apache.org/jira/browse/GEODE-10366 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Using GfshRule default constructor leaves test directories around. It's > supposed to automatically delete the test directories after the test > completes. This is not a blocker for 1.15 but the fix should be merged to > develop and possibly support/1.15 unless it's frozen for release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10366) Using GfshRule default constructor leaves test directories around
[ https://issues.apache.org/jira/browse/GEODE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10366: -- Labels: (was: needsTriage) > Using GfshRule default constructor leaves test directories around > - > > Key: GEODE-10366 > URL: https://issues.apache.org/jira/browse/GEODE-10366 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Priority: Major > > Using GfshRule default constructor leaves test directories around. It's > supposed to automatically delete the test directories after the test > completes. This is not a blocker for 1.15 but the fix should be merged to > develop and possibly support/1.15 unless it's frozen for release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10366) Using GfshRule default constructor leaves test directories around
[ https://issues.apache.org/jira/browse/GEODE-10366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10366: -- Affects Version/s: 1.15.0 1.16.0 > Using GfshRule default constructor leaves test directories around > - > > Key: GEODE-10366 > URL: https://issues.apache.org/jira/browse/GEODE-10366 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Priority: Major > > Using GfshRule default constructor leaves test directories around. It's > supposed to automatically delete the test directories after the test > completes. This is not a blocker for 1.15 but the fix should be merged to > develop and possibly support/1.15 unless it's frozen for release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10366) Using GfshRule default constructor leaves test directories around
Kirk Lund created GEODE-10366: - Summary: Using GfshRule default constructor leaves test directories around Key: GEODE-10366 URL: https://issues.apache.org/jira/browse/GEODE-10366 Project: Geode Issue Type: Bug Components: tests Reporter: Kirk Lund Using GfshRule default constructor leaves test directories around. It's supposed to automatically delete the test directories after the test completes. This is not a blocker for 1.15 but the fix should be merged to develop and possibly support/1.15 unless it's frozen for release. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Fix Version/s: 1.16.0 > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-9615.
--
Fix Version/s: 1.15.0
1.16.0
Resolution: Fixed
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
in develop and
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
in support/1.15
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.15.0, 1.16.0
>
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
>
[jira] [Updated] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9615:
-
Affects Version/s: 1.14.0
1.13.0
1.15.0
1.16.0
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --name=locator-chase-obedient-cake]] expected:<[0]> but was:<[1]>
> at
>
[jira] [Resolved] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10327. --- Fix Version/s: 1.15.0 Resolution: Fixed Fixed by https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629 in develop and https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b in support/1.15 > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550613#comment-17550613
]
Kirk Lund edited comment on GEODE-10360 at 6/6/22 7:08 PM:
---
Sorry for confusion, my changes in
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
did not fix GEODE-10360
was (Author: klund):
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
and backported to 1.15 in
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
>
[jira] [Reopened] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reopened GEODE-10360:
---
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
> Fix For: 1.15.0
>
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
>
[jira] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10360:
--
Fix Version/s: (was: 1.15.0)
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
>
[jira] [Resolved] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-10360.
---
Fix Version/s: 1.15.0
Resolution: Fixed
Fixed by
https://github.com/apache/geode/commit/495f3b0cffe0d0200521c266ea26c9e53cf6d629
and backported to 1.15 in
https://github.com/apache/geode/commit/ee9d674efaebdb8407af38a74f29a6094c2a6f3b
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Nabarun Nag
>Priority: Major
> Labels: blocks-1.16.0
> Fix For: 1.15.0
>
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
>
[jira] [Resolved] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6222.
--
Resolution: Fixed
GEODE-6222 has been replaced by GEODE-6489.
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0, 1.14.0, 1.15.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-6489) CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
[
https://issues.apache.org/jira/browse/GEODE-6489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6489:
-
Summary: CI Failures with GemFireDeadlockDetectorDUnitTest >
testDistributedDeadlock (was: CI Failures with testDistributedDeadlock)
> CI Failures with GemFireDeadlockDetectorDUnitTest > testDistributedDeadlock
> ---
>
> Key: GEODE-6489
> URL: https://issues.apache.org/jira/browse/GEODE-6489
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.14.0, 1.15.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Jinmei Liao
>Priority: Major
> Labels: flaky
>
> In an single CI run, we see 3 failures all related to testDistributedDeadlock:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> {noformat}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/469
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testDistributedDeadlockWithFunction FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> org.apache.geode.management.internal.cli.commands.ShowDeadlockOverHttpDUnitTest
> > testNoDeadlock FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$68/829260532.run
> in VM 1 running on Host ceb4d948b5be with 4 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase
> was not fulfilled within 300 seconds.
> 137 tests completed, 2 failed
> > Task :geode-web:distributedTest FAILED
> > Task :geode-core:distributedTest
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:201)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-results/distributedTest/1551833386/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0019/test-artifacts/1551833386/distributedtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0019.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-438) CI failure: MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection
[
https://issues.apache.org/jira/browse/GEODE-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-438.
-
Resolution: Duplicate
GEODE-438 has been replaced by GEODE-7822.
> CI failure: MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection
>
>
> Key: GEODE-438
> URL: https://issues.apache.org/jira/browse/GEODE-438
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Kirk Lund
>Priority: Minor
> Labels: CI, Flaky
>
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$16.call
> in VM 1 running on Host cc6-co6.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:360)
> at dunit.VM.invoke(VM.java:303)
> at dunit.VM.invoke(VM.java:271)
> at
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:558)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:49)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: junit.framework.AssertionFailedError: Event never occurred after
> 3000 ms: verify critical state
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> dunit.DistributedTestCase.waitForCriterion(DistributedTestCase.java:1162)
> at
> com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$16.call(MemoryThresholdsOffHeapDUnitTest.java:610)
> at
[jira] [Updated] (GEODE-923) CI failure: ConnectionManagerJUnitTest.testIdleExpiration
[
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] [Updated] (GEODE-9089) Two SerialWANStatsDUnitTest.testReplicatedSerialPropagation... Test Variants Fail
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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
[
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>
[
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] [Updated] (GEODE-10361) AutoConnectionSourceImplIntegrationTest > test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators with NoAvailableLocatorsException
[
https://issues.apache.org/jira/browse/GEODE-10361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
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] [Updated] (GEODE-10360) ConcurrentParallelGatewaySenderOffHeapDistributedTest > testPartitionedParallelPropagationHA fails with timeout because queue doesn't drain
[
https://issues.apache.org/jira/browse/GEODE-10360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10360:
--
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
[
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
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] [Reopened] (GEODE-1957) CI failure: DiskRegionAsyncRecoveryJUnitTest.testCloseOpenRegion
[
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] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the {{nodes}} stat in DistributionStats.
Understanding why this change is not allowed requires understanding the
difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE, however,
some locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in the locator in that JVM having LOCATOR_DM_TYPE. Otherwise
is of type NORMAL_DM_TYPE. Usage of FORCE_LOCATOR_DM_TYPE is considered an API
until Geode 2.0 because it was documented for Users at some point and has been
actively used in scripting and tooling for Geode.
DistributionStats {{nodes}} is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the {{nodes}} stat in DistributionStats.
Understanding why this change is not allowed requires understanding the
difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE, however,
some locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in the locator in that JVM having LOCATOR_DM_TYPE. Otherwise
is of type NORMAL_DM_TYPE.
DistributionStats {{nodes}} is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the {{nodes}} stat in DistributionStats.
> Understanding why this change is not allowed requires understanding the
> difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE,
> however, some locators are of the type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in the locator in that JVM having LOCATOR_DM_TYPE.
> Otherwise is of type NORMAL_DM_TYPE. Usage of FORCE_LOCATOR_DM_TYPE is
> considered an API until Geode 2.0 because it was documented for Users at some
> point and has been actively used in scripting and tooling for Geode.
> DistributionStats {{nodes}} is defined as NOT counting processes of type
> LOCATOR_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the {{nodes}} stat in DistributionStats.
Understanding why this change is not allowed requires understanding the
difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE, however,
some locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in the locator in that JVM having LOCATOR_DM_TYPE. Otherwise
is of type NORMAL_DM_TYPE.
DistributionStats {{nodes}} is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE, however,
some locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in the locator in that JVM having LOCATOR_DM_TYPE. Otherwise
is of type NORMAL_DM_TYPE.
DistributionStats {{nodes}} is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the {{nodes}} stat in DistributionStats.
> Understanding why this change is not allowed requires understanding the
> difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE,
> however, some locators are of the type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in the locator in that JVM having LOCATOR_DM_TYPE.
> Otherwise is of type NORMAL_DM_TYPE.
> DistributionStats {{nodes}} is defined as NOT counting processes of type
> LOCATOR_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE, however,
some locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in the locator in that JVM having LOCATOR_DM_TYPE. Otherwise
is of type NORMAL_DM_TYPE.
DistributionStats {{nodes}} is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, some
locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
DistributionStats nodes is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the nodes stat in DistributionStats and the
> author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
> NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh are both of type NORMAL_DM_TYPE,
> however, some locators are of the type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in the locator in that JVM having LOCATOR_DM_TYPE.
> Otherwise is of type NORMAL_DM_TYPE.
> DistributionStats {{nodes}} is defined as NOT counting processes of type
> LOCATOR_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, some
locators are of the type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
DistributionStats nodes is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
locators were of type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
DistributionStats nodes is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the nodes stat in DistributionStats and the
> author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
> NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, some
> locators are of the type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
> NORMAL_DM_TYPE.
> DistributionStats nodes is defined as NOT counting processes of type
> LOCATOR_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
locators were of type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
DistributionStats nodes is defined as NOT counting processes of type
LOCATOR_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
locators were of type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the nodes stat in DistributionStats and the
> author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
> NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
> locators were of type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
> NORMAL_DM_TYPE.
> DistributionStats nodes is defined as NOT counting processes of type
> LOCATOR_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[
https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10358:
--
Description:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
locators were of type LOCATOR_DM_TYPE.
Older scripts and tools set:
{noformat}
System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
{noformat}
which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
NORMAL_DM_TYPE.
was:
Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
PR #6225 is trying to redefine the nodes stat in DistributionStats and the
author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
NORMAL_DM_TYPE.
Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
locators were of type LOCATOR_DM_TYPE.
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
>
>
> Key: GEODE-10358
> URL: https://issues.apache.org/jira/browse/GEODE-10358
> Project: Geode
> Issue Type: Wish
> Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE.
> PR #6225 is trying to redefine the nodes stat in DistributionStats and the
> author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and
> NORMAL_DM_TYPE.
> Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very
> locators were of type LOCATOR_DM_TYPE.
> Older scripts and tools set:
> {noformat}
> System.setProperty(InternalLocator.FORCE_LOCATOR_DM_TYPE, "true");
> {noformat}
> which then results in Locators having LOCATOR_DM_TYPE. Otherwise they are
> NORMAL_DM_TYPE.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
[ https://issues.apache.org/jira/browse/GEODE-10358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-10358: - Assignee: Kirk Lund > Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE > > > Key: GEODE-10358 > URL: https://issues.apache.org/jira/browse/GEODE-10358 > Project: Geode > Issue Type: Wish > Components: membership, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE. > PR #6225 is trying to redefine the nodes stat in DistributionStats and the > author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and > NORMAL_DM_TYPE. > Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very > locators were of type LOCATOR_DM_TYPE. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10358) Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE
Kirk Lund created GEODE-10358: - Summary: Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE Key: GEODE-10358 URL: https://issues.apache.org/jira/browse/GEODE-10358 Project: Geode Issue Type: Wish Components: membership, tests Reporter: Kirk Lund Add test coverage for LOCATOR_DM_TYPE and NORMAL_DM_TYPE. PR #6225 is trying to redefine the nodes stat in DistributionStats and the author seems to be unfamiliar with the difference between LOCATOR_DM_TYPE and NORMAL_DM_TYPE. Servers and Locators started via Gfsh both have NORMAL_DM_TYPE, however, very locators were of type LOCATOR_DM_TYPE. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes. This range needs to be much
lower.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log output and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
[jira] [Updated] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
[
https://issues.apache.org/jira/browse/GEODE-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10333:
--
Affects Version/s: 1.15.0
1.16.0
> WANRollingUpgradeNewSenderProcessOldEvent >
> bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
> geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding
> to heartbeat requests
> --
>
> Key: GEODE-10333
> URL: https://issues.apache.org/jira/browse/GEODE-10333
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
> during geode-wan:upgradeTest which is running tests in parallel. To be
> well-behaved all ports must come from AvailablePortHelper and be well below
> the range of ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk8
> Gradle target: geode-wan:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes. This range needs to be much
> lower.
> # The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
> enough info so debugging this test will require a lot of digging through log
> output and studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
> in VM 5, Host Host
> heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
> with 7 VMs, Geode 1.7.0, Java 8
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
> at
> org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log output and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Affects Version/s: 1.15.0
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Affects Version/s: 1.16.0
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
> geode-core:upgradeTest which is running tests in parallel. To be well-behaved
> all ports must come from AvailablePortHelper and be well below the range of
> ephemeral ports.
> Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
> Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
> parameter)
> Test job: upgrade-test-openjdk11
> Gradle target: geode-core:upgradeTest
> This failure was seen during repeated precheckin runs for PR #7571. The test
> does not use GfshRule and we determined that the changes for VmConfiguration
> are not involved in this failure. Initial analysis of output suggests that
> some of the following test problems might be contributing:
> # Some ports are using AvailablePortHelper while others seem to be using
> default ports. Any use of default ports will eventually cause failures of one
> or more tests when they run in parallel.
> # The membership port range configured for the test is too high. It's up in
> the ephemeral port range which means it's eventually going to collide with
> ephemeral ports being used by other processes.
> # The assertions in ClientAuthenticationTestCase don't provide enough info so
> debugging this test will require a lot of digging through log output and
> studying test code in multiple class files.
> To fix this failure, I would start out by fixing up all port usage by the
> test.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Created] (GEODE-10333) WANRollingUpgradeNewSenderProcessOldEvent > bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8, geode=1.7.0}] fails with ForcedDisconnectExcepti
Kirk Lund created GEODE-10333:
-
Summary: WANRollingUpgradeNewSenderProcessOldEvent >
bothOldAndNewEventsShouldBeProcessedByOldSender[From VmConfiguration{java=8,
geode=1.7.0}] fails with ForcedDisconnectException: Member isn't responding to
heartbeat requests
Key: GEODE-10333
URL: https://issues.apache.org/jira/browse/GEODE-10333
Project: Geode
Issue Type: Bug
Components: membership, tests
Reporter: Kirk Lund
NOTE: WANRollingUpgradeNewSenderProcessOldEvent is a dunit test that runs
during geode-wan:upgradeTest which is running tests in parallel. To be
well-behaved all ports must come from AvailablePortHelper and be well below the
range of ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371948
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426563/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk8
Gradle target: geode-wan:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range configured for the test is too high. It's up in the
ephemeral port range which means it's eventually going to collide with
ephemeral ports being used by other processes. This range needs to be much
lower.
# The assertions in WANRollingUpgradeNewSenderProcessOldEvent don't provide
enough info so debugging this test will require a lot of digging through log
output and studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$344/1994402702.run
in VM 5, Host Host
heavy-lifter-f7f182f0-e980-587e-9bf7-d23392538e69.c.apachegeode-ci.internal
with 7 VMs, Geode 1.7.0, Java 8
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
at
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startAndConfigureServers(WANRollingUpgradeDUnitTest.java:191)
at
org.apache.geode.cache.wan.WANRollingUpgradeNewSenderProcessOldEvent.bothOldAndNewEventsShouldBeProcessedByOldSender(WANRollingUpgradeNewSenderProcessOldEvent.java:276)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. The test
does not use GfshRule and we determined that the changes for VmConfiguration
are not involved in this failure. Initial analysis of output suggests that some
of the following test problems might be contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
To fix this failure, I would start out by fixing up all port usage by the test.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
Precheckin run: https://concourse.apachegeode-ci.info/builds/56371942
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7571/test-results/upgradeTest/1653426348/
Failure occurred: during the upgrade from Geode 1.7.0 (value of junit test
parameter)
Test job: upgrade-test-openjdk11
Gradle target: geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
NOTE: ClientAuthenticationDUnitTest is a dunit test that runs during
geode-core:upgradeTest which is running tests in parallel. To be well-behaved
all ports must come from AvailablePortHelper and be well below the range of
ephemeral ports.
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging of this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Description:
geode-core:upgradeTest
This failure was seen during repeated precheckin runs for PR #7571. Initial
analysis of output suggests that some of the following test problems might be
contributing:
# Some ports are using AvailablePortHelper while others seem to be using
default ports. Any use of default ports will eventually cause failures of one
or more tests when they run in parallel.
# The membership port range is too high. It's up in the ephemeral port range
which means it's eventually going to collide with ephemeral ports being used by
other processes.
# The assertions in ClientAuthenticationTestCase don't provide enough info so
debugging of this test will require a lot of digging through log files and
studying test code in multiple class files.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException after MembershipConfigura
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails with SocketTimeoutException after MembershipConfigurationException (was:
ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException)
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> after MembershipConfigurationException
> --
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Component/s: membership
tests
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails
>
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
>
[jira] [Updated] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10332:
--
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails with SocketTimeoutException (was: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails )
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client
> VmConfiguration{java=11, geode=1.7.0}] fails with SocketTimeoutException
> ---
>
> Key: GEODE-10332
> URL: https://issues.apache.org/jira/browse/GEODE-10332
> Project: Geode
> Issue Type: Bug
> Components: membership, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
> in VM 1, Host Host
> heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
> with 4 VMs, Geode 10240.0.0, Java 11
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
>
[jira] [Created] (GEODE-10332) ClientAuthenticationDUnitTest > testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}] fails
Kirk Lund created GEODE-10332:
-
Summary: ClientAuthenticationDUnitTest >
testCredentialsForNotifications[Client VmConfiguration{java=11, geode=1.7.0}]
fails
Key: GEODE-10332
URL: https://issues.apache.org/jira/browse/GEODE-10332
Project: Geode
Issue Type: Bug
Reporter: Kirk Lund
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$490/0x00010041e040.call
in VM 1, Host Host
heavy-lifter-afcd3383-60cd-5694-909f-3bc9af935683.c.apachegeode-ci.internal
with 4 VMs, Geode 10240.0.0, Java 11
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
at org.apache.geode.test.dunit.VM.invoke(VM.java:525)
at
org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:595)
at
org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:104)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
[jira] [Updated] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Description: GfshRule needs to cleanup all processes it forks. It also needs to save off all runtime artifacts such as logging, stats, pid files, diskstores to enable debugging of test failures. (was: Enhance GfshRule for debugging and prevention of test pollution. Update every test that uses GfshRule to allow bigger changes to GfshRule as well as receiving the full benefit of this major overhaul. GfshRule does not currently save off artifacts for failed test runs. It also leaves behind orphaned locator and server processes that were spawned by Gfsh.) > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > GfshRule needs to cleanup all processes it forks. It also needs to save off > all runtime artifacts such as logging, stats, pid files, diskstores to enable > debugging of test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Summary: Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures (was: Enhance GfshRule for debugging and prevention of test pollution) > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Enhance GfshRule for debugging and prevention of test pollution. Update every > test that uses GfshRule to allow bigger changes to GfshRule as well as > receiving the full benefit of this major overhaul. > GfshRule does not currently save off artifacts for failed test runs. It also > leaves behind orphaned locator and server processes that were spawned by Gfsh. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Tests that use GfshRule leave behind orphaned processes and do not save artifacts for debugging failures
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Issue Type: Bug (was: Improvement) > Tests that use GfshRule leave behind orphaned processes and do not save > artifacts for debugging failures > > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Enhance GfshRule for debugging and prevention of test pollution. Update every > test that uses GfshRule to allow bigger changes to GfshRule as well as > receiving the full benefit of this major overhaul. > GfshRule does not currently save off artifacts for failed test runs. It also > leaves behind orphaned locator and server processes that were spawned by Gfsh. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Enhance GfshRule for debugging and prevention of test pollution
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Description: Enhance GfshRule for debugging and prevention of test pollution. Update every test that uses GfshRule to allow bigger changes to GfshRule as well as receiving the full benefit of this major overhaul. GfshRule does not currently save off artifacts for failed test runs. It also leaves behind orphaned locator and server processes that were spawned by Gfsh. was:Update all precheckin tests to enable use of JDK 17 and fix any test failures. > Enhance GfshRule for debugging and prevention of test pollution > --- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Enhance GfshRule for debugging and prevention of test pollution. Update every > test that uses GfshRule to allow bigger changes to GfshRule as well as > receiving the full benefit of this major overhaul. > GfshRule does not currently save off artifacts for failed test runs. It also > leaves behind orphaned locator and server processes that were spawned by Gfsh. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Enhance GfshRule for debugging and prevention of test pollution
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Summary: Enhance GfshRule for debugging and prevention of test pollution (was: Update all precheckin tests for JDK 17) > Enhance GfshRule for debugging and prevention of test pollution > --- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Update all precheckin tests for JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Affects Version/s: 1.15.0 1.16.0 > Update all precheckin tests for JDK 17 > -- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Update all precheckin tests for JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Issue Type: Improvement (was: Bug) > Update all precheckin tests for JDK 17 > -- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0, 1.16.0 >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10327) Update all precheckin tests for JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-10327: -- Labels: Java17 (was: needsTriage) > Update all precheckin tests for JDK 17 > -- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > > Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- 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>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-10323:
-
Assignee: (was: Kirk Lund)
> 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: Improvement
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10323:
--
Issue Type: Bug (was: Improvement)
> 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: needsTriage, 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] [Assigned] (GEODE-10327) Update all precheckin tests for JDK 17
[ https://issues.apache.org/jira/browse/GEODE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-10327: - Assignee: Kirk Lund > Update all precheckin tests for JDK 17 > -- > > Key: GEODE-10327 > URL: https://issues.apache.org/jira/browse/GEODE-10327 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: needsTriage > > Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- 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>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-10323:
-
Assignee: Kirk Lund
> 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: Improvement
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: needsTriage, 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] [Created] (GEODE-10327) Update all precheckin tests for JDK 17
Kirk Lund created GEODE-10327: - Summary: Update all precheckin tests for JDK 17 Key: GEODE-10327 URL: https://issues.apache.org/jira/browse/GEODE-10327 Project: Geode Issue Type: Bug Components: tests Reporter: Kirk Lund Update all precheckin tests to enable use of JDK 17 and fix any test failures. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10323:
--
Issue Type: Improvement (was: Bug)
> 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: Improvement
> Components: offheap
>Affects Versions: 1.16.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10323:
--
Affects Version/s: 1.16.0
> 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: needsTriage, pull-request-available
>
> [Please see 1st comment on this ticket below the description for
> recommendation on how to fix.]
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}} started failing
> intermittently due to commit a350ed2 which went in as
> "[GEODE-10087|https://issues.apache.org/jira/browse/GEODE-10087]: Enhance
> off-heap fragmentation visibility.
> ([#7407|https://github.com/apache/geode/pull/7407/commits/1640effc5c760afa8d9ec4c2743950bb1de0ef8f])".
> The failure stack looks like:
> {noformat}
> OffHeapStorageJUnitTest > testCreateOffHeapStorage FAILED
> java.lang.AssertionError: expected:<100> but was:<1048576>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.offheap.OffHeapStorageJUnitTest.testCreateOffHeapStorage(OffHeapStorageJUnitTest.java:220)
> {noformat}
> The cause is in {{MemoryAllocatorImpl}}. A new scheduled executor
> {{updateNonRealTimeStatsExecutor}} was added near the bottom of the
> constructor which immediately gets scheduled to invoke
> {{freeList::updateNonRealTimeStats}} repeatedly at the specified frequency of
> {{updateOffHeapStatsFrequencyMs}} whenever an instance of
> {{MemoryAllocatorImpl}} is created.
> {{freeList::updateNonRealTimeStats}} then updates {{setLargestFragment}} and
> {{setFreedChunks}}.
> Scheduling or starting any sort of threads from a constructor is considered a
> bad practice and should only be done via some sort of activation method such
> as {{start()}} which can be invoked from the static factory method for
> {{MemoryAllocatorImpl}}. The unit tests would then continue to construct
> instances via a constructor that does NOT invoke {{start()}}.
> {{OffHeapStorageJUnitTest testCreateOffHeapStorage}}, and possibly other
> tests, is written with the assumption that no other thread or component can
> or will be updating the {{OffHeapStats}}. Hence it is then safe for the test
> to setLargestFragment and then assert that it has the value passed in:
> {noformat}
> 219: stats.setLargestFragment(100);
> 220: assertEquals(100, stats.getLargestFragment());
> {noformat}
> Line 220 is the source of the assertion failure because
> {{updateNonRealTimeStatsExecutor}} is racing with the JUnit thread and
> changes the value of {{setLargestFragment}} immediately after the test sets
> the value to 100, but before the test invokes the assertion.
> Looking back at the [PR test
> results|https://cio.hdb.gemfire-ci.info/commits/pr/7407/junit?days=90] we can
> see that stress-new-test failed 5 times with this exact failure before being
> merged to develop:
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646140652/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646154134/
> (x2)
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646156997/
> *
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7407/test-results/repeatTest/1646170346/
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10323:
--
Description:
[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/
was:
{{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
[jira] [Comment Edited] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539849#comment-17539849
]
Kirk Lund edited comment on GEODE-10323 at 5/19/22 11:22 PM:
-
Here's our best recommendation for a fix.
Move the scheduling of {{updateNonRealTimeStatsFuture}} out of the constructor
for {{MemoryAllocatorImpl}}:
{noformat}
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
{noformat}
To a new method called {{start()}} or something similar:
{noformat}
void start() {
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
}
{noformat}
Add a call to {{start()}} near just before returning the newly created
{{MemoryAllocatorImpl}} from the static factory method {{private static
MemoryAllocatorImpl create(...)}}.
{noformat}
result.start();
return result;
}
{noformat}
The newer tests introduced by PR #7407 should then use one of the static
factory methods that invokes {{start()}} near the end just before returning the
new instance of {{MemoryAllocatorImpl}}.
{{MemoryAllocatorImpl}} has acquired too many static factory methods including
two named {{createForUnitTest}}. The use of methods "ForUnitTest" is a bad
practice, but the more concerning problem here is that these static factory
methods have a lot of duplicated code between them and they don't funnel
through each other.
Tests that need to inject dependencies or different values should call into a
static factory method is also being called by the product's code path. The test
can then use the same code and provide different dependencies or different
values while still using the same code path. Use of
{{java.util.function.Supplier}} for dependencies that may need it can also
help make things more flexible for testing.
was (Author: klund):
Here's the best recommendation for a fix.
Move the scheduling of {{updateNonRealTimeStatsFuture}} out of the constructor
for MemoryAllocatorImpl:
{noformat}
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
{noformat}
To a new method called {{start()}} or something similar:
{noformat}
void start() {
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
}
{noformat}
Add a call to {{start()}} near just before returning the newly created
{{MemoryAllocatorImpl}} from the static factory method {{private static
MemoryAllocatorImpl create(...)}}.
{noformat}
result.start();
return result;
}
{noformat}
The newer tests introduced by PR #7407 should then use one of the static
factory methods that invokes {{start()}} near the end just before returning the
new instance of {{MemoryAllocatorImpl}}.
{{MemoryAllocatorImpl}} has acquired too many static factory methods including
two named {{createForUnitTest}}. The use of methods "ForUnitTest" is a bad
practice, but the more concerning problem here is that these static factory
methods have a lot of duplicated code between them and they don't funnel
through each other.
Tests that need to inject dependencies or different values should call into a
static factory method is also being called by the product's code path. The test
can then use the same code and provide different dependencies or different
values while still using the same code path. Use of
{{java.util.function.Supplier}} for dependencies that may need it can also
help make things more flexible for testing.
> 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
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {{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
>
[jira] [Comment Edited] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539849#comment-17539849
]
Kirk Lund edited comment on GEODE-10323 at 5/19/22 11:22 PM:
-
Here's the best recommendation for a fix.
Move the scheduling of {{updateNonRealTimeStatsFuture}} out of the constructor
for MemoryAllocatorImpl:
{noformat}
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
{noformat}
To a new method called {{start()}} or something similar:
{noformat}
void start() {
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
}
{noformat}
Add a call to {{start()}} near just before returning the newly created
{{MemoryAllocatorImpl}} from the static factory method {{private static
MemoryAllocatorImpl create(...)}}.
{noformat}
result.start();
return result;
}
{noformat}
The newer tests introduced by PR #7407 should then use one of the static
factory methods that invokes {{start()}} near the end just before returning the
new instance of {{MemoryAllocatorImpl}}.
{{MemoryAllocatorImpl}} has acquired too many static factory methods including
two named {{createForUnitTest}}. The use of methods "ForUnitTest" is a bad
practice, but the more concerning problem here is that these static factory
methods have a lot of duplicated code between them and they don't funnel
through each other.
Tests that need to inject dependencies or different values should call into a
static factory method is also being called by the product's code path. The test
can then use the same code and provide different dependencies or different
values while still using the same code path. Use of
{{java.util.function.Supplier}} for dependencies that may need it can also
help make things more flexible for testing.
was (Author: klund):
Here's the best recommendation for a fix.
Move the scheduling of xxx out of the constructor for MemoryAllocatorImpl:
{noformat}
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
{noformat}
To a new method called {{start()}} or something similar:
{noformat}
void start() {
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
}
{noformat}
Add a call to {{start()}} near just before returning the newly created
{{MemoryAllocatorImpl}} from the static factory method {{private static
MemoryAllocatorImpl create(...)}}.
{noformat}
result.start();
return result;
}
{noformat}
The newer tests introduced by PR #7407 should then use one of the static
factory methods that invokes {{start()}} near the end just before returning the
new instance of {{MemoryAllocatorImpl}}.
{{MemoryAllocatorImpl}} has acquired too many static factory methods including
two named {{createForUnitTest}}. The use of methods "ForUnitTest" is a bad
practice, but the more concerning problem here is that these static factory
methods have a lot of duplicated code between them and they don't funnel
through each other.
Tests that need to inject dependencies or different values should call into a
static factory method is also being called by the product's code path. The test
can then use the same code and provide different dependencies or different
values while still using the same code path. Use of
{{java.util.function.Supplier}} for dependencies that may need it can also
help make things more flexible for testing.
> 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
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {{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
[jira] [Commented] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
[
https://issues.apache.org/jira/browse/GEODE-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539849#comment-17539849
]
Kirk Lund commented on GEODE-10323:
---
Here's the best recommendation for a fix.
Move the scheduling of xxx out of the constructor for MemoryAllocatorImpl:
{noformat}
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
{noformat}
To a new method called {{start()}} or something similar:
{noformat}
void start() {
updateNonRealTimeStatsFuture =
updateNonRealTimeStatsExecutor.scheduleAtFixedRate(freeList::updateNonRealTimeStats,
0,
updateOffHeapStatsFrequencyMs, TimeUnit.MILLISECONDS);
}
{noformat}
Add a call to {{start()}} near just before returning the newly created
{{MemoryAllocatorImpl}} from the static factory method {{private static
MemoryAllocatorImpl create(...)}}.
{noformat}
result.start();
return result;
}
{noformat}
The newer tests introduced by PR #7407 should then use one of the static
factory methods that invokes {{start()}} near the end just before returning the
new instance of {{MemoryAllocatorImpl}}.
{{MemoryAllocatorImpl}} has acquired too many static factory methods including
two named {{createForUnitTest}}. The use of methods "ForUnitTest" is a bad
practice, but the more concerning problem here is that these static factory
methods have a lot of duplicated code between them and they don't funnel
through each other.
Tests that need to inject dependencies or different values should call into a
static factory method is also being called by the product's code path. The test
can then use the same code and provide different dependencies or different
values while still using the same code path. Use of
{{java.util.function.Supplier}} for dependencies that may need it can also
help make things more flexible for testing.
> 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
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {{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
[jira] [Created] (GEODE-10323) OffHeapStorageJUnitTest testCreateOffHeapStorage fails with AssertionError: expected:<100> but was:<1048576>
Kirk Lund created GEODE-10323:
-
Summary: 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
Reporter: Kirk Lund
{{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-9987) Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
[
https://issues.apache.org/jira/browse/GEODE-9987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539692#comment-17539692
]
Kirk Lund commented on GEODE-9987:
--
This precheckin failure hit GEODE-9987:
https://concourse.apachegeode-ci.info/builds/54633956
> Mass-Test_Run: HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
>
>
> Key: GEODE-9987
> URL: https://issues.apache.org/jira/browse/GEODE-9987
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> {code:java}
> HostedLocatorsDUnitTest > testGetAllHostedLocators FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal
> with 4 VMs
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm3.log' at line 458
> [fatal 2022/01/22 17:02:39.638 UTC receiver,heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204-65003> tid=125]
> Membership service failure: Member isn't responding to heartbeat requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1806)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1120)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:723)
> ...
> Caused by:
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.HostedLocatorsDUnitTest$1.call in VM 3 running
> on Host
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.distributed.HostedLocatorsDUnitTest.testGetAllHostedLocators(HostedLocatorsDUnitTest.java:92)
> Caused by:
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204(heavy-lifter-a104d1cf-827a-5a63-b549-400f89cd9204.c.apachegeode-ci.internal_HostedLocatorsDUnitTest_testGetAllHostedLocators-3:115919:locator):59339
> started at Sat Jan 22 17:02:21 UTC 2022: Member isn't responding to
> heartbeat requests, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2686)
> at
> org.apache.geode.distributed.internal.locks.DLockService.create(DLockService.java:2660)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getOrCreateService(DLockService.java:2641)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.(InternalConfigurationPersistenceService.java:131)
> at
> org.apache.geode.distributed.internal.InternalLocator.startConfigurationPersistenceService(InternalLocator.java:1390)
> at
> org.apache.geode.distributed.internal.InternalLocator.startClusterManagementService(InternalLocator.java:792)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:787)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:768)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:399)
> at
>
[jira] [Updated] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9615:
-
Description:
This failure occurs because the locator or server was stopped and then
immediately restarted with the same ports. When Gfsh returns from stop locator
or stop server, the stopped process is asynchronously stopping and may continue
to hold those ports when the next start command for that process is issued. It
then fails with an exit value of 1 instead of the expected value of 0.
Any test using GfshRule to stop and then immediately start a new process may
fail in this way. The underlying exception in the locator or server log is a
BindException because the port is still in use by the previous instance of that
process which is still in the process of stopping.
The only way to close this gap is to have the test get the pid for the process
being stopped and then await until the process identified by that pid no longer
exists.
{code:java}
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
org.junit.ComparisonFailure: [Exit value from process started by
[test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
--host=localhost --port=20608]] expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
at
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
at
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
org.junit.ComparisonFailure: [Exit value from process started by
[test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
--dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
at
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
at
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
org.junit.ComparisonFailure: [Exit value from process started by
[test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
--name=locator-chase-obedient-cake]] expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
at
org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
at
[jira] [Assigned] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-9615:
Assignee: Kirk Lund
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> This failure occurs because the locator or server was stopped and then
> immediately restarted with the same ports. When Gfsh returns from stop
> locator or stop server, the stopped process is asynchronously stopping and
> may continue to hold those ports when the next start command for that process
> is issued. It then fails with an exit value of 1 instead of the expected
> value of 0.
> Any test using GfshRule to stop and then immediately start a new process may
> fail in this way. The underlying exception in the locator or server log is a
> BindException because the port is still in use by the previous instance of
> that process which is still in the process of stopping.
> The only way to close this gap is to have the test get the pid for the
> process being stopped and then await until the process identified by that pid
> no longer exists.
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --name=locator-chase-obedient-cake]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
>
[jira] [Updated] (GEODE-9615) CI Failure: Acceptance Tests fails with exit value 1 from start locator or start server
[
https://issues.apache.org/jira/browse/GEODE-9615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9615:
-
Summary: CI Failure: Acceptance Tests fails with exit value 1 from start
locator or start server (was: CI Failure: Acceptance Tests fails with exit
value 1 from start locator)
> CI Failure: Acceptance Tests fails with exit value 1 from start locator or
> start server
> ---
>
> Key: GEODE-9615
> URL: https://issues.apache.org/jira/browse/GEODE-9615
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> {code:java}
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --host=localhost --port=20608]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.onlineStatusCommandShouldSucceedWhenConnected_locator_host_and_port(StatusLocatorExitCodeAcceptanceTest.java:128)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > offlineStatusCommandShouldSucceedWhenConnected_locator_dir FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --dir=/tmp/junit11722670533134972918/member-controller/locator-chase-obedient-cake]]
> expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.offlineStatusCommandShouldSucceedWhenConnected_locator_dir(StatusLocatorExitCodeAcceptanceTest.java:140)
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest
> > onlineStatusCommandShouldSucceedWhenConnected_locator_name FAILED
> org.junit.ComparisonFailure: [Exit value from process started by
> [test-frame: gfsh -e connect --locator=localhost[20608] -e status locator
> --name=locator-chase-obedient-cake]] expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:137)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:128)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusLocatorExitCodeAcceptanceTest.executeScriptWithExpectedExitCode(StatusLocatorExitCodeAcceptanceTest.java:255)
> at
>
[jira] [Closed] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund closed GEODE-10209.
-
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
>
[jira] [Resolved] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-10209.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
>
[jira] [Resolved] (GEODE-10159) Upgrade to Micrometer 1.9
[ https://issues.apache.org/jira/browse/GEODE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10159. --- Resolution: Not A Problem (was: Fixed) > Upgrade to Micrometer 1.9 > - > > Key: GEODE-10159 > URL: https://issues.apache.org/jira/browse/GEODE-10159 > Project: Geode > Issue Type: Sub-task > Components: statistics >Reporter: Udo Kohlmeyer >Priority: Major > Labels: Java17 > Fix For: 1.15.0 > > > Micrometer 2.x introduces a new set of issues: > * Not being released in time for 9.15 > * Package name restructuring > * External public API's directly exposing the Micrometer classes, need to be > updated, and in so any external projects depending the exposed API > In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, > Micrometer is releasing 1.9 version that will be the bridge between 1.x and > 2.x. > Spring Data Geode has already tested that updating to this version resolves > the issues that it has when integrating with Spring Boot 3.0, and deems this > version to be good. > Micrometer 1.9 has not made GA yet, but it is expected to be released around > May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is > scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10159) Upgrade to Micrometer 1.9
[ https://issues.apache.org/jira/browse/GEODE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund closed GEODE-10159. - Assignee: Kirk Lund > Upgrade to Micrometer 1.9 > - > > Key: GEODE-10159 > URL: https://issues.apache.org/jira/browse/GEODE-10159 > Project: Geode > Issue Type: Sub-task > Components: statistics >Reporter: Udo Kohlmeyer >Assignee: Kirk Lund >Priority: Major > Labels: Java17 > Fix For: 1.15.0 > > > Micrometer 2.x introduces a new set of issues: > * Not being released in time for 9.15 > * Package name restructuring > * External public API's directly exposing the Micrometer classes, need to be > updated, and in so any external projects depending the exposed API > In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, > Micrometer is releasing 1.9 version that will be the bridge between 1.x and > 2.x. > Spring Data Geode has already tested that updating to this version resolves > the issues that it has when integrating with Spring Boot 3.0, and deems this > version to be good. > Micrometer 1.9 has not made GA yet, but it is expected to be released around > May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is > scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10159) Upgrade to Micrometer 1.9
[ https://issues.apache.org/jira/browse/GEODE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10159. --- Fix Version/s: 1.15.0 Resolution: Fixed I'll reopen if Micrometer 1.9 or 1.10 releases in time for Apache Geode 1.15. For now, it looks like Micrometer 2.0 has been shelved indefinitely and all compatibility concerns have been addressed. > Upgrade to Micrometer 1.9 > - > > Key: GEODE-10159 > URL: https://issues.apache.org/jira/browse/GEODE-10159 > Project: Geode > Issue Type: Sub-task > Components: statistics >Reporter: Udo Kohlmeyer >Priority: Major > Labels: Java17 > Fix For: 1.15.0 > > > Micrometer 2.x introduces a new set of issues: > * Not being released in time for 9.15 > * Package name restructuring > * External public API's directly exposing the Micrometer classes, need to be > updated, and in so any external projects depending the exposed API > In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, > Micrometer is releasing 1.9 version that will be the bridge between 1.x and > 2.x. > Spring Data Geode has already tested that updating to this version resolves > the issues that it has when integrating with Spring Boot 3.0, and deems this > version to be good. > Micrometer 1.9 has not made GA yet, but it is expected to be released around > May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is > scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10159) Upgrade to Micrometer 1.9
[ https://issues.apache.org/jira/browse/GEODE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund closed GEODE-10159. - > Upgrade to Micrometer 1.9 > - > > Key: GEODE-10159 > URL: https://issues.apache.org/jira/browse/GEODE-10159 > Project: Geode > Issue Type: Sub-task > Components: statistics >Reporter: Udo Kohlmeyer >Priority: Major > Labels: Java17 > Fix For: 1.15.0 > > > Micrometer 2.x introduces a new set of issues: > * Not being released in time for 9.15 > * Package name restructuring > * External public API's directly exposing the Micrometer classes, need to be > updated, and in so any external projects depending the exposed API > In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, > Micrometer is releasing 1.9 version that will be the bridge between 1.x and > 2.x. > Spring Data Geode has already tested that updating to this version resolves > the issues that it has when integrating with Spring Boot 3.0, and deems this > version to be good. > Micrometer 1.9 has not made GA yet, but it is expected to be released around > May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is > scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10219) CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and support/1.13
[ https://issues.apache.org/jira/browse/GEODE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-10219. --- Fix Version/s: 1.12.10 1.13.9 Resolution: Fixed Fixed by reverting serialization filter backports. > CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and > support/1.13 > --- > > Key: GEODE-10219 > URL: https://issues.apache.org/jira/browse/GEODE-10219 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.12.10, 1.13.9 >Reporter: Joris Melchior >Assignee: Kirk Lund >Priority: Major > Labels: needsTriage > Fix For: 1.12.10, 1.13.9 > > > Repeated failure of `acceptance-test-openjdk11` with tests being unable to > properly shut down members as part of the tests. > See > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/acceptance-test-openjdk11/builds/51] > See > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/42] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (GEODE-10219) CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and support/1.13
[ https://issues.apache.org/jira/browse/GEODE-10219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund closed GEODE-10219. - > CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and > support/1.13 > --- > > Key: GEODE-10219 > URL: https://issues.apache.org/jira/browse/GEODE-10219 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.12.10, 1.13.9 >Reporter: Joris Melchior >Assignee: Kirk Lund >Priority: Major > Labels: needsTriage > Fix For: 1.12.10, 1.13.9 > > > Repeated failure of `acceptance-test-openjdk11` with tests being unable to > properly shut down members as part of the tests. > See > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/acceptance-test-openjdk11/builds/51] > See > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/42] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10228:
--
Fix Version/s: 1.15.0
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10228:
--
Description:
{{testDurableHAFailover}} has a history of flakiness, thought the stacks do
seem to have changed some since the older versions of the but were resolved.
{noformat}
urableClientTestCase > testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
expected: null
but was: "0"="0" within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
Caused by:
org.opentest4j.AssertionFailedError:
expected: null
but was: "0"="0"
at
sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
{noformat}
was:
{noformat}
urableClientTestCase > testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
expected: null
but was: "0"="0" within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
Caused by:
org.opentest4j.AssertionFailedError:
expected: null
but was: "0"="0"
at
sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
{noformat}
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {{testDurableHAFailover}} has
[jira] [Created] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
Kirk Lund created GEODE-10228:
-
Summary: CI Failure: DurableClientTestCase > testDurableHAFailover
times out in await for failover
Key: GEODE-10228
URL: https://issues.apache.org/jira/browse/GEODE-10228
Project: Geode
Issue Type: Bug
Components: client/server, tests
Reporter: Kirk Lund
{noromat}
urableClientTestCase > testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
expected: null
but was: "0"="0" within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
Caused by:
org.opentest4j.AssertionFailedError:
expected: null
but was: "0"="0"
at
sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-10228:
--
Description:
{noformat}
urableClientTestCase > testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
expected: null
but was: "0"="0" within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
Caused by:
org.opentest4j.AssertionFailedError:
expected: null
but was: "0"="0"
at
sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
{noformat}
was:
{noromat}
urableClientTestCase > testDurableHAFailover FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
on Host
heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
with 4 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.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition
defined as a lambda expression in
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
expected: null
but was: "0"="0" within 5 minutes.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
Caused by:
org.opentest4j.AssertionFailedError:
expected: null
but was: "0"="0"
at
sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
{noformat}
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
>
