[jira] [Updated] (GEODE-10452) geode-kafka-connector uses log4shell affected log4j-core
[ https://issues.apache.org/jira/browse/GEODE-10452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10452: -- Labels: needsTriage (was: ) > geode-kafka-connector uses log4shell affected log4j-core > > > Key: GEODE-10452 > URL: https://issues.apache.org/jira/browse/GEODE-10452 > Project: Geode > Issue Type: Bug >Reporter: PJ Fanning >Priority: Major > Labels: needsTriage > > See https://github.com/apache/geode-kafka-connector/pull/20 > Is geode-kafka-connector maintained? If not, could it be archived. > It feels wrong for an ASF project to have source that is using log4shell > affected jars in 2024. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10451) insecure confluent http url used in geode-kafka-connector build
[ https://issues.apache.org/jira/browse/GEODE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10451: -- Labels: needsTriage (was: ) > insecure confluent http url used in geode-kafka-connector build > > > Key: GEODE-10451 > URL: https://issues.apache.org/jira/browse/GEODE-10451 > Project: Geode > Issue Type: Bug >Reporter: PJ Fanning >Priority: Major > Labels: needsTriage > > https://github.com/apache/geode-kafka-connector/blob/37992b8d7331cd8d131e5c8ce971763a2f7eb8ca/pom.xml#L55 > Please use https only - otherwise, we are at risk of someone spoofing the > HTTP address and injecting dangerous code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10450) Update spring version for CVE-2023-20861
[
https://issues.apache.org/jira/browse/GEODE-10450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10450:
--
Labels: needsTriage (was: )
> Update spring version for CVE-2023-20861
>
>
> Key: GEODE-10450
> URL: https://issues.apache.org/jira/browse/GEODE-10450
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.1
>Reporter: Ankush Mittal
>Priority: Major
> Labels: needsTriage
>
> As per [https://nvd.nist.gov/vuln/detail/CVE-2023-20861],
> "{_}In Spring Framework versions 6.0.0 - 6.0.6, 5.3.0 - 5.3.25, 5.2.0.RELEASE
> - 5.2.22.RELEASE, and older unsupported versions, it is possible for a user
> to provide a specially crafted SpEL expression that may cause a
> denial-of-service (DoS) condition.{_}"
>
> Geode bundles version 5.3.20 which is vulnerable as per the CVE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10449) Update shiro-core to version 1.12.0 for CVE-2023-34478
[ https://issues.apache.org/jira/browse/GEODE-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10449: -- Labels: needsTriage (was: ) > Update shiro-core to version 1.12.0 for CVE-2023-34478 > -- > > Key: GEODE-10449 > URL: https://issues.apache.org/jira/browse/GEODE-10449 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.1 >Reporter: Ankush Mittal >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2023-34478] , > _"Apache Shiro, before 1.12.0 or 2.0.0-alpha-3, may be susceptible to a path > traversal attack that results in an authentication bypass when used together > with APIs or other web frameworks that route requests based on non-normalized > requests. Mitigation: Update to Apache Shiro 1.12.0+ or 2.0.0-alpha-3+"_ > Geode 1.15.1 bundles version 1.9.1 of shiro-core jar which is vulnerable as > per the CVE. > > There is another CVE related to shiro-core 1.9.1, > [https://nvd.nist.gov/vuln/detail/CVE-2023-22602] , > which states > "When using Apache Shiro before 1.11.0 together with Spring Boot 2.6+, a > specially crafted HTTP request may cause an authentication bypass. The > authentication bypass occurs when Shiro and Spring Boot are using different > pattern-matching techniques. Both Shiro and Spring Boot < 2.6 default to Ant > style pattern matching. Mitigation: Update to Apache Shiro 1.11.0, or set the > following Spring Boot configuration value: > `spring.mvc.pathmatch.matching-strategy = ant_path_matcher`" > > Fix for the mentioned vulnerabilities seems to be merged in "develop" branch > via commit > [https://github.com/apache/geode/commit/d1958146c12affb1fe3eabc5823bb4eeb6c0badc] > Logging this Jira to update the same in 1.15.1 branch as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10448) CVE-2022-42889 Apache Commons Text security vulnerability in Apache Geode
[ https://issues.apache.org/jira/browse/GEODE-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10448: -- Labels: needsTriage (was: ) > CVE-2022-42889 Apache Commons Text security vulnerability in Apache Geode > - > > Key: GEODE-10448 > URL: https://issues.apache.org/jira/browse/GEODE-10448 > Project: Geode > Issue Type: Bug > Components: pulse, tools >Affects Versions: 1.15.1 >Reporter: Eli >Priority: Major > Labels: needsTriage > > I have encountered the security vulnerability > [CVE-2022-42889|https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om] > related to Apache Commons Text. It is mentioned that the mitigation is to > "Upgrade to [Apache Commons Text > 1.10.0|https://commons.apache.org/proper/commons-text/download_text.cgi].; > because the following jar files are present. > /locator01/GemFire_gemfire/services/http/0.0.0.0_7070_pulse_/webapp/WEB-INF/lib/commons-text-1.9.jar > > /locator01/GemFire_root/services/http/0.0.0.0_7070_pulse_/webapp/WEB-INF/lib/commons-text-1.9.jar > The latest official [Apache Geode version > 1.15.1|[https://apache.org/dyn/closer.cgi/geode/1.15.1/apache-geode-1.15.1.tgz|https://urldefense.com/v3/__https:/apache.org/dyn/closer.cgi/geode/1.15.1/apache-geode-1.15.1.tgz__;!!OrxsNty6D4my!7476fkBhS9dRAajU_LNsgk5KeehflkDwT1rsdOg5_lmW9F-rnt-zPr7K5J66Ylc8jzr9eR10QsOBYlTmJR0Y8tDl8ik$]] > has the vulnerable file commons-text-1.9.jar, which falls under the affected > range “version 1.5 and continuing through 1.9”. Inside the folder > /tools/Pulse, there is the file geode-pulse-1.15.1.war. Inside > that war file, there is the file > geode-pulse-1.15.1.war/WEB-INF/lib/commons-text-1.9.jar. > As a temporary workaround, I replaced the file commons-text-1.9.jar with > commons-text-1.10.0.jar, updated the MANIFEST.MF file under > geode-pulse-1.15.1.war/META-INF, and created a new geode-pulse-1.15.1.war > file including the 2 updated files mentioned. > Unfortunately, I’m not a developer. I’m not familiar with Github, so as much > as I would like to help in contributing in the code, there is a more > appropriate person to perform the update to commons-text 1.10.0. I have sent > a mail to ASF Security Team, and I was given this > [link|[https://github.com/apache/geode/blob/master/build-tools/geode-dependency-management/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy#L144|https://urldefense.com/v3/__https:/github.com/apache/geode/blob/master/build-tools/geode-dependency-management/src/main/groovy/org/apache/geode/gradle/plugins/DependencyConstraints.groovy*L144__;Iw!!OrxsNty6D4my!6EKoN5DUPbSrn9BPavV5jC0T1h5U4Ih1aqdG5cHGJt2a0fqw2jCVoWL4Nl1lCC4hkzC3buVr9YC30Y_jxCSk43yE-FU$]] > that shows the dependency on the vulnerable commons-text version 1.9. > Can somebody assist in fixing this security vulnerability? Thank you in > advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10443) Update shiro-core to version 1.11.0 for CVE-2022-40664
[ https://issues.apache.org/jira/browse/GEODE-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10443: -- Labels: needsTriage (was: ) > Update shiro-core to version 1.11.0 for CVE-2022-40664 > -- > > Key: GEODE-10443 > URL: https://issues.apache.org/jira/browse/GEODE-10443 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.1 >Reporter: Ankush Mittal >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2022-40664] , > _"Apache Shiro before 1.10.0, Authentication Bypass Vulnerability in Shiro > when forwarding or including via RequestDispatcher."_ > > Geode 1.15.1 bundles version 1.9.1 of shiro-core jar which is vulnerable as > per the CVE. > > Also although the CVE doesn't include "1.10.0", but since more latest version > "1.11.0" is available, logged ticket to bundle the same. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10432) Jackson-databind 2.13.2.2 has security vulnerabilities. Recommend upgrade to 2.13.4.2.
[ https://issues.apache.org/jira/browse/GEODE-10432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10432: -- Labels: needsTriage (was: ) > Jackson-databind 2.13.2.2 has security vulnerabilities. Recommend upgrade to > 2.13.4.2. > -- > > Key: GEODE-10432 > URL: https://issues.apache.org/jira/browse/GEODE-10432 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Alastair >Priority: Major > Labels: needsTriage > > In Geode 1.15.0, Jackson-databind 2.13.2.2 has known security > vulnerabilities. These issues are both fixed in 2.13.4.2. > > |HIGH|CVE-2022-42004 (BDSA-2022-2768) > [CVE-2022-42004 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-42004]|Jackson Databind > Vulnerable to Denial-of-Service (DoS) via Resource Exhaustion in > 'BeanDeserializer' Component|Fixed in 2.13.4| > |HIGH|CVE-2022-42003 (BDSA-2022-2765) > [CVE-2022-42003 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-42003]|Jackson Databind > Vulnerable to Denial-of-Service (DoS) via Resource Exhaustion in Primitive > Value Deserializers|Fixed in 2.13.4.2| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10431) SnakeYAML 1.3.0 has known security vulnerabilities (5)
[ https://issues.apache.org/jira/browse/GEODE-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10431: -- Labels: needsTriage (was: ) > SnakeYAML 1.3.0 has known security vulnerabilities (5) > -- > > Key: GEODE-10431 > URL: https://issues.apache.org/jira/browse/GEODE-10431 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Alastair >Priority: Major > Labels: needsTriage > > Five (one High, four Medium) vulnerabilities are being reported in SnakeYAML > which is part of Geode 1.15.0. The issues are fixed in SnakeYAML 1.33. > > |HIGH|CVE-2022-25857 (BDSA-2022-2579) > [CVE-2022-25857 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-25857]|SnakeYAML > Vulnerable to Denial-of-Service (DoS) via Lack of Nested Depth Limitation for > Collections|Fixed in 1.33| > |MEDIUM|CVE-2022-38752 (BDSA-2022-2590) > [CVE-2022-38752 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-38752]|SnakeYAML > Vulnerable to Denial-of-Service (DoS) via Stack Overflow Caused by > 'ArrayList' Recursion|Fixed in 1.33| > |MEDIUM|CVE-2022-38751 (BDSA-2022-2587) > [CVE-2022-38751 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-38751]|SnakeYAML > Vulnerable to Denial-of-Service (DoS) via Regular Expression > Mishandling|Fixed in 1.33| > |MEDIUM|CVE-2022-38749 (BDSA-2022-2577) > [CVE-2022-38749 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-38749]|SnakeYAML > Vulnerable to Denial-of-Service (DoS) via Stack-Based Buffer Overflow in > Parsing of Untrusted YAML Files|Fixed in 1.33| > |MEDIUM|CVE-2022-38750 (BDSA-2022-2578) > [CVE-2022-38750 > (nist.gov)|https://nvd.nist.gov/vuln/detail/CVE-2022-38750]|SnakeYAML > Vulnerable to Denial-of-Service (DoS) via Stack-Based Buffer Overflow in > 'BaseConstructor.java'|Fixed in 1.33| > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10430) Update JGroups to 4.+ to address CVE
[ https://issues.apache.org/jira/browse/GEODE-10430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10430: -- Labels: needsTriage (was: ) > Update JGroups to 4.+ to address CVE > > > Key: GEODE-10430 > URL: https://issues.apache.org/jira/browse/GEODE-10430 > Project: Geode > Issue Type: Bug > Components: security >Affects Versions: 1.15.1 >Reporter: Luke DiGiacomo >Priority: Major > Labels: needsTriage > > The latest release of Geode, 1.15.1, declares a dependency on JGroups 3.6.14. > This version of JGroups is subject to a critical CVE, > [https://nvd.nist.gov/vuln/detail/CVE-2016-2141,] which requires moving to > JGroups 4.+. Geode's dependency on JGroups should be bumped to version 4.+ > and any related bug should be addressed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10428) Could not find method dependencySubstitution() for arguments
[
https://issues.apache.org/jira/browse/GEODE-10428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10428:
--
Labels: needsTriage (was: )
> Could not find method dependencySubstitution() for arguments
>
>
> Key: GEODE-10428
> URL: https://issues.apache.org/jira/browse/GEODE-10428
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.15.1
>Reporter: Martin Filla
>Priority: Major
> Labels: needsTriage
>
> Hi,
> i tried build geode from your source code 1.15.1 and I have issue with gradle
> gradle -v
>
> Gradle 7.5.1
>
> Build time: 2022-08-05 21:17:56 UTC
> Revision: d1daa0cbf1a0103000b71484e1dbfe096e095918
> Kotlin: 1.6.21
> Groovy: 3.0.10
> Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021
> JVM: 1.8.0_332 (OpenJDK BSD Porting Team 25.332-b09)
> OS: FreeBSD 13.1-RELEASE-p1 amd64
> {code:java}
> ===> License APACHE20 accepted by the user
> ===> geode-1.15.1 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by geode-1.15.1 for building
> ===> Extracting for geode-1.15.1
> => SHA256 Checksum OK for apache-geode-1.15.1-src.tgz.
> ===> Patching for geode-1.15.1
> ===> geode-1.15.1 depends on package: gradle>0 - found
> ===> geode-1.15.1 depends on file: /usr/local/openjdk8/bin/java - found
> ===> Configuring for geode-1.15.1
> ===> Building for geode-1.15.1
> cd /code/FreeBSD-Ports/geode/work/apache-geode-1.15.1-src && /usr/bin/env
> XDG_DATA_HOME=code/FreeBSD-Ports/geode/work
> XDG_CONFIG_HOME=/mediacode/FreeBSD-Ports/geode/work
> XDG_CACHE_HOME=/code/FreeBSD-Ports/geode/work/.cache
> HOME=/code/FreeBSD-Ports/geode/work
> PATH=/code/FreeBSD-Ports/geode/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin
>
> PKG_CONFIG_LIBDIR=/code/FreeBSD-Ports/geode/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig
> DONTSTRIP=yes NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no
> SHELL=/bin/sh NO_LINT=YES PREFIX=/usr/local LOCALBASE=/usr/local CC="cc"
> CFLAGS="-pipe -g -fstack-protector-strong -fno-strict-aliasing " CPP="cpp"
> CPPFLAGS="" LDFLAGS=" -fstack-protector-strong " LIBS="" CXX="c++"
> CXXFLAGS="-pipe -g -fstack-protector-strong -fno-strict-aliasing "
> MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -m 555"
> BSD_INSTALL_LIB="install -m 0644" BSD_INSTALL_SCRIPT="install -m 555"
> BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" gradle
> --parallel generate --gradle-user-home /tmp/gradle-geode
> FAILURE: Build failed with an exception.
> * Where:
> Settings file
> '/code/FreeBSD-Ports/geode/work/apache-geode-1.15.1-src/settings.gradle'
> line: 23
> * What went wrong:
> A problem occurred evaluating settings 'apache-geode-1.15.1-src'.
> > Could not find method dependencySubstitution() for arguments
> > [settings_1p36shybhlyrknqn0ir9496w0$_run_closure1$_closure2$_closure5@12ff39de]
> > on object of type
> > org.gradle.internal.composite.DefaultConfigurableIncludedPluginBuild.
> * Try:
> > Run with --stacktrace option to get the stack trace.
> > Run with --info or --debug option to get more log output.
> > Run with --scan to get full insights.
> * Get more help at https://help.gradle.org
> BUILD FAILED in 7s
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10427) fake weight when server rebuild
[ https://issues.apache.org/jira/browse/GEODE-10427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10427: -- Labels: needsTriage (was: ) > fake weight when server rebuild > --- > > Key: GEODE-10427 > URL: https://issues.apache.org/jira/browse/GEODE-10427 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.14.4, 1.15.1 >Reporter: jiuzhou liu >Priority: Major > Labels: needsTriage > > The 1+1+1 design we used locked one server during the reinstallation process, > but after locking it, we found that the wrong region was calculated in its > data and passed to the other two servers, resulting in the other two servers > stopped serving. We want to know the following two questions: > how the weight value is calculated? > how does this weight transfer to another geored site? > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10420) Handle WAN event when interrupted
[ https://issues.apache.org/jira/browse/GEODE-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10420: -- Labels: needsTriage (was: ) > Handle WAN event when interrupted > - > > Key: GEODE-10420 > URL: https://issues.apache.org/jira/browse/GEODE-10420 > Project: Geode > Issue Type: Bug >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > It is possible that an event of which a gateway sender is to be notified is > lost if during the process the thread is interrupted. > -- 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=17602556#comment-17602556
]
Alexander Murmann commented on GEODE-10415:
---
Hi [~WeijieEST]. I think this one should just be a dependency update. Since you
volunteered on the mailing list to bump dependencies, I figured it might make
sense to assign this to you, so that you can resolve it once you bumped
versions. Please feel of course free to unassign if this didn't make sense.
> 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
]
Alexander Murmann reassigned GEODE-10415:
-
Assignee: Weijie Xu (was: 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: 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] [Updated] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10418: -- Labels: needsTriage (was: ) > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10417) Fix NullPointerException when getting events from the gw sender queue to complete transactions
[ https://issues.apache.org/jira/browse/GEODE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10417: -- Labels: needsTriage (was: ) > Fix NullPointerException when getting events from the gw sender queue to > complete transactions > -- > > Key: GEODE-10417 > URL: https://issues.apache.org/jira/browse/GEODE-10417 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > When the WAN group-transaction-events feature is enabled, it is possible to > get a NullPointerException when retrieving events from the queue to complete > a transaction if the event in the queue is null. > If this situation is reached then the gateway sender dispatcher will not > dispatch queue events anymore and therefore the WAN replication will not > progress. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10415:
--
Labels: needsTriage (was: )
> 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
>Priority: Major
> 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-10413) Upgrade to Jetty 9.4.48.v20220622
[ https://issues.apache.org/jira/browse/GEODE-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10413: -- Labels: needsTriage (was: ) > Upgrade to Jetty 9.4.48.v20220622 > - > > Key: GEODE-10413 > URL: https://issues.apache.org/jira/browse/GEODE-10413 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Alastair >Priority: Major > Labels: needsTriage > > The current version of Geode 1.15.0 uses Jetty 9.4.46.v20220331 which has the > following security vulnerabilities: > HIGH > * CVE-2022-2048 (BDSA-2022-1887) > LOW > * BDSA-2022-1891 > Jetty 9.4.48.v20220622 has no known vulnerabilities. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10412) Destry region command doesn't clear the region related expired tombstones
[
https://issues.apache.org/jira/browse/GEODE-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10412:
--
Labels: needsTriage (was: )
> Destry region command doesn't clear the region related expired tombstones
> -
>
> Key: GEODE-10412
> URL: https://issues.apache.org/jira/browse/GEODE-10412
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> Tombstones in geode are kept on two maps: expiredTombstones and tombstones
> (non-expired ones). When a region is destroyed, it must clear all the related
> expired and non-expired tombstones from memory. Due to the below code bug,
> expired tombstones aren't cleared when non-expired tombstones are available
> during the region destruction:
> private boolean removeIf(Predicate predicate) {
> return removeUnexpiredIf(predicate) || removeExpiredIf(predicate);
> }
> Because of the above, non-expired tombstones are never removed from memory,
> preventing other tombstones from being cleared. Since other tombstones never
> expire, the compaction is not done, and therefore the disk is filled, causing
> the issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser
[ https://issues.apache.org/jira/browse/GEODE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10411: -- Labels: needsTriage (was: ) > XSS vulnerabiltiy in Pulse data browser > --- > > Key: GEODE-10411 > URL: https://issues.apache.org/jira/browse/GEODE-10411 > Project: Geode > Issue Type: Bug > Components: pulse >Affects Versions: 1.12.9, 1.12.10, 1.14.4, 1.14.5, 1.15.0, 1.15.1, 1.16.0 >Reporter: Joris Melchior >Priority: Major > Labels: needsTriage > > # Description: > Stored XSS via data injection into Geode database, the injected > payload eventually gets executed on Pulse web application when the > admin querying data from Geode. > # PoC: > Step 1: With Geode up and running, run gfsh command to get into > interactive mode: > shell$ gfsh > Step 2: In gfsh console, execute the following command to insert a > data entry into regionA (assume that regionA is created before). Note > that the value of this data entry contains JavaScript code: > gfsh> put --region=regionA --key="test" --value="alert(1)" > Step 3: Open browser to query editor of Pulse web application at > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0 > (assume that already > logged in as admin), execute the following query: > SELECT * FROM /regionA > Step 4: Data from regionA will be retrieved, the XSS payload > eventually get executed > # Why this is an issue? > Developer maybe saves user-controlled data to Geode database, users > maybe submit data via an arbitrary client application (for example, a > web application), the use of gfsh console just simplifies the PoC. > # IMPACT: > Exploiting this XSS vulnerability, an attacker can steal the admin's > session cookie, therefore take over the admin account. > # CVSS: 7.6 HIGH > (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0 > ) > (re-calculate if not correct) > # Fix: > The Pulse web application must URL encode data retrieved from Geode database. > # Credit: > The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10410) Rebalance Guard Prevent Lost Bucket Recovery
[ https://issues.apache.org/jira/browse/GEODE-10410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10410: -- Labels: needsTriage (was: ) > Rebalance Guard Prevent Lost Bucket Recovery > > > Key: GEODE-10410 > URL: https://issues.apache.org/jira/browse/GEODE-10410 > Project: Geode > Issue Type: Bug >Reporter: Weijie Xu >Priority: Major > Labels: needsTriage > > Following steps reproduce the issue: > Run the start.gfsh in the attached example, which configures a geode system > with a partitioned region and a gateway sender. So there are two regions, the > manually created region, and the queue region. > Then run the example code, which will source ~400M data and 5 times amount of > events into the system. All data are sourced into the system, no bucket lost, > and no out of memory. > Then stop one of the server, and revoke the disk file of the server. > Then start the server, which will trigger a bucket recovery. After that, > there will be part of secondary bucket lost. > gfsh>show metrics --region=/example-region > | numBucketsWithoutRedundancy | 63 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10409) Rebalance Model Missing Collocated Regions At Server Startup
[ https://issues.apache.org/jira/browse/GEODE-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10409: -- Labels: needsTriage (was: ) > Rebalance Model Missing Collocated Regions At Server Startup > > > Key: GEODE-10409 > URL: https://issues.apache.org/jira/browse/GEODE-10409 > Project: Geode > Issue Type: Bug >Reporter: Weijie Xu >Priority: Major > Labels: needsTriage > > Following steps reproduce the issue: > Run the start.gfsh in the attached example, which configures a geode system > with a partitioned region, a gateway sender and a collocated region with the > partitioned region. So there are three regions totally, the leader region, > the collcated region and the queue region. > Then run the example code, which will source ~400M data and 5 times amount of > events into the system. > Then stop one of the server, and revoke the disk file of the server. > Then start the server, which will trigger a bucket recovery. > From the attached log line596, line598 and line5958, we can see that the > queue region is not included in the rebalance model, either in the data size > colum nor in the max size colum. > Then do a manual rebalance after the server is up, this time log shows the > queue region is added to the model.(line6010, line6012, lin6014 and line6028) > > The inconsistent behavior will lead to 2 negative results: > 1) Different result of rebalance between server startup phase and manual > trigger, startup rebalance tells everything is OK, rebalance finished, but > manual trigger rebalance tells space not enough since it included the queue > region into the model which has 5 times data size as the leader region. > 2) A dismatch between the rebalance model and the actual data being > rebalanced(Actually the queue region data is rebalanced although the region > is not included in the model at server startup phase). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10407) java.lang.LinkageError: loader org.apache.geode.internal.DeployJarChildFirstClassLoader @2b0a05b0 attempted duplicate class definition for org.apache.kafka.common.KafkaE
[ https://issues.apache.org/jira/browse/GEODE-10407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10407: -- Labels: needsTriage (was: ) > java.lang.LinkageError: loader > org.apache.geode.internal.DeployJarChildFirstClassLoader @2b0a05b0 attempted > duplicate class definition for org.apache.kafka.common.KafkaException > - > > Key: GEODE-10407 > URL: https://issues.apache.org/jira/browse/GEODE-10407 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Mario Ivanac >Priority: Major > Labels: needsTriage > > When creating region with CacheListener, LinkageError error is detected -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10406) Update shiro-core to version 1.9.1 for CVE-2022-32532
[ https://issues.apache.org/jira/browse/GEODE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10406: -- Labels: needsTriage (was: ) > Update shiro-core to version 1.9.1 for CVE-2022-32532 > -- > > Key: GEODE-10406 > URL: https://issues.apache.org/jira/browse/GEODE-10406 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.7 >Reporter: Ankush Mittal >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2022-32532] > "Apache Shiro before 1.9.1, A RegexRequestMatcher can be misconfigured to be > bypassed on some servlet containers. Applications using RegExPatternMatcher > with `.` in the regular expression are possibly vulnerable to an > authorization bypass." > Geode bundles version 1.8.0 of shiro-core jar which is vulnerable as per the > CVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10404) Fix compilation for Java 11
[
https://issues.apache.org/jira/browse/GEODE-10404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10404:
--
Labels: needsTriage (was: )
> Fix compilation for Java 11
> ---
>
> Key: GEODE-10404
> URL: https://issues.apache.org/jira/browse/GEODE-10404
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage
>
> It seems that after merging #973, compilation with Geode Native Docker build
> image for version 1.15.0 is broken. This is the compilation error:
> {noformat}
> tests/javaobject/ComparePdxInstanceFunction.java:42: error: unmappable
> character (0xAC) for encoding US-ASCII
> pdxInstanceFactory.writeString("utfHugeField", longString + "???");
> {noformat}
> As it seems, the latest docker image is using Java 11, which handles UTF-8
> strings in a different way to Java 8, so that's why compilation is working
> with packer images and not with Docker build image.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10403) Distributed deadlock when stopping gateway sender
[ https://issues.apache.org/jira/browse/GEODE-10403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10403: -- Labels: needsTriage (was: ) > Distributed deadlock when stopping gateway sender > - > > Key: GEODE-10403 > URL: https://issues.apache.org/jira/browse/GEODE-10403 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0 >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > A distributed deadlock has been found during some tests of a Geode system > with WAN replication when stopping the gateway sender while sending a fair > amount of operations to the servers. > The distributed deadlock manifests in the gateway sender stop command hanging > forever and by all normal Geode operations from clients (gets, puts,...) not > being responded. > The situation is provoked by the Gateway sender stop command that first takes > the lifecycle lock and then, at a given point, tries to retrieve the size of > the gateway sender. This operation, that requires communication with the > other peers never finishes, probably because the response from one of the > peers is never received. > Another thread is blocked when trying to acquire the lifecycle lock in > AbstractGatewaySender.distribute(). > Finally many threads handling Geode operations (get, put...) get blocked in > the DistributedCacheOperation._distribute() call waiting for a response from > another peer. > Thread dump section from blocked gateway sender stop command in call to get > size of queue: > "ConcurrentParallelGatewaySenderEventProcessor Stopper Thread4" #1319 daemon > prio=10 os_prio=0 cpu=46.95ms elapsed=4152.76s tid=0x7f92bc1bb000 > nid=0x2157 waiting on condition [0x7f9179bd1000] >java.lang.Thread.State: TIMED_WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method) > - parking to wait for <0x00031ca2cbd8> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:1079) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.11/AbstractQueuedSynchronizer.java:1369) > at > java.util.concurrent.CountDownLatch.await(java.base@11.0.11/CountDownLatch.java:278) > at > org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) > at > org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865) > at > org.apache.geode.internal.cache.partitioned.SizeMessage$SizeResponse.waitBucketSizes(SizeMessage.java:344) > at > org.apache.geode.internal.cache.PartitionedRegion.getSizeRemotely(PartitionedRegion.java:6758) > at > org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6709) > at > org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6691) > at > org.apache.geode.internal.cache.PartitionedRegion.getRegionSize(PartitionedRegion.java:6663) > at > org.apache.geode.internal.cache.LocalRegionDataView.entryCount(LocalRegionDataView.java:99) > at > org.apache.geode.internal.cache.LocalRegion.entryCount(LocalRegion.java:2078) > at > org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8301) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.size(ParallelGatewaySenderQueue.java:1670) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.closeProcessor(AbstractGatewaySenderEventProcessor.java:1259) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.stopProcessing(AbstractGatewaySenderEventProcessor.java:1247) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor$SenderStopperCallable.call(AbstractGatewaySenderEventProcessor.java:1399) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor$SenderStopperCallable.call(AbstractGatewaySenderEventProcessor.java:1387) > at >
[jira] [Updated] (GEODE-10402) Fix FunctionException handling
[ https://issues.apache.org/jira/browse/GEODE-10402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10402: -- Labels: needsTriage (was: ) > Fix FunctionException handling > -- > > Key: GEODE-10402 > URL: https://issues.apache.org/jira/browse/GEODE-10402 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a ServerFunction throwing a FunctionException > *WHEN* its executed > *THEN* a CacheServerException is thrown rather FunctionException > > *Additional info.* FunctionException seems not to be handled, that's why the > default handling exception is thrown by the native API, CacheServerException -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10401) Oplog recovery takes too long due to fault in fastutil library
[
https://issues.apache.org/jira/browse/GEODE-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10401:
--
Labels: needsTriage (was: )
> Oplog recovery takes too long due to fault in fastutil library
> --
>
> Key: GEODE-10401
> URL: https://issues.apache.org/jira/browse/GEODE-10401
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> {color:#0e101a}As we already know, the .drf file delete operations only
> contain OplogEntryID. During recovery, the server reads (byte by byte) each
> OplogEntryID and stores it in a HashSet to use later when recovering .crf
> files. There are two types of HashSets: IntOpenHashSet and LongOpenHashSet.
> The OplogEntryID of type
> {color}_{color:#0e101a}integer{color}_{color:#0e101a} will be stored in
> IntOpenHashSet, and {color}_{color:#0e101a}long
> integer{color}_{color:#0e101a} in LongOpenHashSet, probably due to memory
> optimization and performance factors. OplogEntryID starts with a zero and
> increments throughout time. Recovery speed could differ depending on which
> HashSet is used, so please consider that when estimating .drf recovery
> time.{color}
>
> {color:#0e101a}We have observed in logs that between exception (There is a
> large number of deleted entries) and the previous log have passed more than 4
> minutes (sometimes even more).{color}
>
> {color:#0e101a}{"timestamp":"2022-06-14T21:41:43.772+08:00","severity":"info","message":"Recovering
> oplog#271 /opt/dbservice/data/datastore/BACKUPdataDiskStore_271.drf for disk
> store dataDiskStore.","metadata":{color}
> {color:#0e101a}{"timestamp":"2022-06-14T21:46:02.152+08:00","severity":"warning","message":"There
> is a large number of deleted entries within the disk-store, please execute
> an offline{color}
> {color:#0e101a}compaction.","metadata":{color}
> {color:#0e101a} {color}
> {color:#0e101a}When the above exception occurs, that means that the limit of
> {color}_{color:#0e101a}805306401{color}_{color:#0e101a} entries in
> IntOpenHashSet has been reached. In that case, the server rolls to the new
> IntOpenHashSet, where an exception and the delay could happen again.{color}
>
> {color:#0e101a}The problem is that due to the fault in FastUtil dependency
> (IntOpenHashSet and LongOpenHashSet), the unnecessary rehashing happens
> multiple times before the max size is reached. The{color}
> _{color:#0e101a}rehashing starts from{color}_ {color:#0e101a}805306368
> onwards for each new entry until the max size. This rehashing adds several
> minutes to .drf Oplog recovery.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10400) Function execution triggering internal exception
[ https://issues.apache.org/jira/browse/GEODE-10400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10400: -- Labels: needsTriage (was: ) > Function execution triggering internal exception > > > Key: GEODE-10400 > URL: https://issues.apache.org/jira/browse/GEODE-10400 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* a cluster with at least 3 members > *AND* a partitioned region with 1 redundant-copy > *AND* a server function called *JustAFunction* with isHA=false, > hasResult=true, optimizeForWrite=true > *AND* a native client configured to connect to the above cluster with a pool > using PR-Single-Hop=true > *WHEN* *JustAFunction* is executed with onRegion and no filters > *IF* the client has partial metadata due to the cluster starting up or a > rebalance occurring > *THEN* and exception of type > *"org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException: > Multiple target nodes found for single hop operation"* is thrown by one of > the servers > --- > *Additional information.* Currently, in geode-native whenever the metadata > information is incomplete, and the user tries to execute the server function > with onRegion and no filters, a request of type > EXECUTE_REGION_FUNCTION_SINGLE_HOP is sent to each node. > But the issue is that bucket partition used by the client is incorrect, > leading consequently to the mentioned exception. > *Potential solution.* The potential solution would be to detect that the > metadata is incomplete before actually executing the function and send a > EXECUTE_REGION_FUNCTION request to one of the cluster nodes instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10399) CI: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest > test[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10399:
--
Labels: needsTriage (was: )
> CI:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> > test[1.8.0] FAILED
> --
>
> Key: GEODE-10399
> URL: https://issues.apache.org/jira/browse/GEODE-10399
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> It's probably due to environment. Similar to GEODE-9531.
> {code:java}
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> > test[1.8.0] FAILED
> org.opentest4j.AssertionFailedError: [Locator in
> /tmp/junit1239217839732739821/locator on
> heavy-lifter-fbdeb3b6-ac9b-5022-9bde-6fc2316be33d.c.gemfire-dev.internal[10334]
> is currently not responding.
> ]
> expected: OK
> but was: ERROR
> 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.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:108)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.stop(TomcatSessionBackwardsCompatibilityTestBase.java:194)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 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.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-10398) TotalBucketCount are not updated after restart
[ https://issues.apache.org/jira/browse/GEODE-10398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10398: -- Labels: needsTriage (was: ) > TotalBucketCount are not updated after restart > -- > > Key: GEODE-10398 > URL: https://issues.apache.org/jira/browse/GEODE-10398 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > Steps to reproduce the issue: > # start locator and 4 servers(static sampling enabled) > # create disk stores for gw sender and region > # create parallel gw sender with disk store > # create the region with gw sender and disk store > # initialize buckets > # shutdown servers > # get up all servers > # check the member stats > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10397) Meyhomes Capital Phú Quốc Landup
[
https://issues.apache.org/jira/browse/GEODE-10397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10397:
--
Labels: needsTriage (was: )
> Meyhomes Capital Phú Quốc Landup
>
>
> Key: GEODE-10397
> URL: https://issues.apache.org/jira/browse/GEODE-10397
> Project: Geode
> Issue Type: Bug
>Reporter: Meyhomes Capital Phú Quốc Landup
>Priority: Major
> Labels: needsTriage
>
> Thông tin mới về dự án Meyhomes Capital Phú Quốc LandUp
> [https://landup.net/du-an/meyhomes-capital-phu-quoc/], vị trí, thanh toán,
> chiết khấu, giá bán...dự án Meyhomes Capital Phú Quốc của chủ đầu tư Tân Á
> Đại Thành. Dự án có vị trí đắc địa ngay gần bờ biển Bãi Trường, được nhiều
> nhà đầu tư quan tâm tìm mua.
> *Website:* ++ [https://landup.net/du-an/meyhomes-capital-phu-quoc/]
> {*}Youtube{*}: [https://www.youtube.com/channel/UCkXw7NGUetiWxAkET5Vc1WA/]
> *Blog:*
> [https://sites.google.com/view/meyhomescapitalpq-landup/|https://sites.google.com/view/meyhomescapitalpq-landup/trang-ch%E1%BB%A7]
> *Email:* meyhomescapitalphuq...@gmail.com
> *Địa chỉ:* 20 Nguyễn Văn Đậu, Phường 5, Quận Phú Nhuận, Thành phố Hồ Chí Minh
> *Số điện thoại:* 0928.0168.69
> *Tags:* Dự án Meyhomes Capital Phú Quốc, Meyhomes Capital Phú Quốc, BĐS Tân Á
> Đại Thành, Bất động sản Phú Quốc, LandUp, Bất động sản
> *Hashtag:* #meyhomescapital #meyhomescapitalphuquoc #batdongsanphuquoc
> #tanadaithanh #batdongsan #landup
> *Xã hội của tôi:*
> [https://www.facebook.com/Meyhomes-Capital-Ph%C3%BA-Qu%E1%BB%91c-112117104876503]
> [https://www.pinterest.com/meyhomescapitalpqlandup|https://www.pinterest.com/meyhomescapitalpqlandup/]
> [https://twitter.com/MeyhomesCapitaI]
> [https://about.me/meyhomescapitalpqlandup]
> [https://www.behance.net/meyhomescapitalpq]
> [https://meyhomescapitalpqlandup.tumblr.com|https://meyhomescapitalpqlandup.tumblr.com/]
> [https://www.tumblr.com/blog/view/meyhomescapitalpqlandup]
> [https://soundcloud.com/meyhomescapitalpq-landup]
> [https://www.instagram.com/meyhomescapitalpglandup|https://www.instagram.com/meyhomescapitalpglandup/]
> [https://myhomescapitalphuquoclandup.wordpress.com/]
> [https://meyhomescapitalpqlandup.weebly.com/]
> [https://github.com/meyhomescapitalpq-landup]
> [https://meyhomescapitalpq-landup.blogspot.com/2022/07/meyhomes-capital-phu-quoc-landup.html]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10396) IllegalStateException wrapped within FunctionException triggers endpoint disconnection
[ https://issues.apache.org/jira/browse/GEODE-10396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10396: -- Labels: needsTriage (was: ) > IllegalStateException wrapped within FunctionException triggers endpoint > disconnection > -- > > Key: GEODE-10396 > URL: https://issues.apache.org/jira/browse/GEODE-10396 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* A cluster of 3 servers and a client with a pool pointing to those 3 > servers >*AND* configured with PR-Singl-Hop = true > *WHEN* A server function is executed with onRegion and with a filter >*AND* it throws an IllegalServerException wrapped within a > FunctionExceution in the body > *THEN* the native client thinks there is an isue with the node and closes all > the endpoint's connections. > --- > *IT IS TO BE EXPECTED* That given that the exception is wrapped inside a > FunctionException this should be ignored by the endpoint failure detection > mechanism that native client has into place. > *AS ADDITIONAL INFO* Currently, the exception chain relationship info is not > read by the native client, as it's serialized using Java serialization format. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10395) TXLockIdImpl memory leak after CommitConflictException from another node
Title: Message Title Alexander Murmann updated an issue Geode / GEODE-10395 TXLockIdImpl memory leak after CommitConflictException from another node Change By: Alexander Murmann Labels: needsTriage Add Comment This message was sent by Atlassian Jira (v8.20.10#820010-sha1:ace47f9)
[jira] [Updated] (GEODE-10392) Faulty statistics when parallel gateway sender is started with clean queue, on restarted member
[ https://issues.apache.org/jira/browse/GEODE-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10392: -- Labels: needsTriage (was: ) > Faulty statistics when parallel gateway sender is started with clean queue, > on restarted member > --- > > Key: GEODE-10392 > URL: https://issues.apache.org/jira/browse/GEODE-10392 > Project: Geode > Issue Type: Bug > Components: statistics, wan >Reporter: Mario Ivanac >Priority: Major > Labels: needsTriage > > we have following scenario: > we fill parallel gateway-sender queue with some events, restart one server, > and after it is recovered, execute stop gw sender, and then start gw sender > with clean queue option. > At this moment, queue is cleared, and all stats are zero. > After this moment, if we put any data in queue, you can see that stats > getTotalQueueSizeBytesInUse is 0. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10391) Region Operation During Primary Change in P2P-only Configuration Results in Spurious Entry{NotFound|Exists}Exception
[
https://issues.apache.org/jira/browse/GEODE-10391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10391:
--
Labels: needsTriage (was: )
> Region Operation During Primary Change in P2P-only Configuration Results in
> Spurious Entry{NotFound|Exists}Exception
>
>
> Key: GEODE-10391
> URL: https://issues.apache.org/jira/browse/GEODE-10391
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.16.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> When a primary moves while a region operation, e.g. create, is in-flight,
> i.e. started but not yet acknowledged, the operation will be retried
> automatically, until the operation succeeds or fails.
> When a member notices another member has crashed, the surviving member
> requests (from the remaining members) data for which the crashed member had
> been primary (delta-GII/sync). This sync is necessary to regain consistency
> in case the (retrying) requester fails before it can re-issue the request to
> the new primary.
> In GEODE-5055 we learned that we needed to delay that sync request long
> enough for the new primary to be chosen and for the original requester to
> make a new request against the new primary. If we didn't delay the sync, the
> primary could end up with the entry in the new state (as if the operation had
> completed) but without the corresponding event tracker data needed to
> conflate the retried event.
> The fix for GEODE-5055 introduced a delay, but only for configurations where
> clients were present. If only peers were present there would be no delay.
> This ticket pertains to the P2P-only case.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10388) srcDist includes local plugin binaries
[ https://issues.apache.org/jira/browse/GEODE-10388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10388: -- Labels: needsTriage (was: ) > srcDist includes local plugin binaries > -- > > Key: GEODE-10388 > URL: https://issues.apache.org/jira/browse/GEODE-10388 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.15.0, 1.16.0 >Reporter: Robert Houghton >Priority: Major > Labels: needsTriage > > After refactoring buildSrc into buildTools, the exclusion rule for the > `srcDist` task fails to filter out the `build` output directory of the plugin. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal opeartions
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10383:
--
Labels: needsTriage (was: )
> lucene may log many warnings about BucketNotFound during normal opeartions
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10382) Windows build broken after image update
[ https://issues.apache.org/jira/browse/GEODE-10382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10382: -- Labels: needsTriage (was: ) > Windows build broken after image update > --- > > Key: GEODE-10382 > URL: https://issues.apache.org/jira/browse/GEODE-10382 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.16.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > The Windows 2019 build is broken in CI due to a new version of cmake not > liking one of our config parameters, and a couple of new build warnings being > flagged as errors after a compiler update. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10381) CI Failure: SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10381:
--
Labels: needsTriage (was: )
> CI Failure:
> SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]
> FAILED
> --
>
> Key: GEODE-10381
> URL: https://issues.apache.org/jira/browse/GEODE-10381
> Project: Geode
> Issue Type: Bug
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [c4f0c1c64be0eb32: gfsh -e start locator --connect=false
> --http-service-port=0 --name=locator1
> --bind-address=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal
> --port=29435 --J=-Dgemfire.jmx-manager-port=29436
> --security-properties-file=/home/geode/geode/geode-core/build/upgradeTest/test-worker-59/SocketCreatorUpgradeTest/upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties[1.13.1]/newSecurity.properties
>
> --locators=heavy-lifter-53ba3aed-9271-5896-9b10-672aaf4ea707.c.apachegeode-ci.internal[29437]]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:146)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.doExecute(GfshContext.java:157)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:127)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshContext.execute(GfshContext.java:121)
> at
> org.apache.geode.internal.net.SocketCreatorUpgradeTest.upgradingToNewGeodeAndNewJavaWithProtocolsTLSv1_2WithNewProperties(SocketCreatorUpgradeTest.java:507)
> 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.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75)
> at
> org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
>
[jira] [Updated] (GEODE-10380) When dispatcher socket buffer is full. the reauth might won't get sent to the client causing a deadlock
[ https://issues.apache.org/jira/browse/GEODE-10380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10380: -- Labels: needsTriage (was: ) > When dispatcher socket buffer is full. the reauth might won't get sent to the > client causing a deadlock > --- > > Key: GEODE-10380 > URL: https://issues.apache.org/jira/browse/GEODE-10380 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > > # message dispatcher trying to send a reAuth message to the client, but not > able to because the socket buffer is full. > # client updater is blocked waiting for a regionEntry lock when doing a > remove operation. > # the regionEntry lock is held by a client operation doing destroy on that > same key > # the client operation is waiting for the re_auth op to finish. > # the re_auth command on the server is blocked by the #1 holding the lock -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10376) Client event processing waits for event registrations to finish.
[
https://issues.apache.org/jira/browse/GEODE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10376:
--
Labels: needsTriage (was: )
> Client event processing waits for event registrations to finish.
> --
>
> Key: GEODE-10376
> URL: https://issues.apache.org/jira/browse/GEODE-10376
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.16.0
>Reporter: Anilkumar Gingade
>Priority: Major
> Labels: needsTriage
>
> Currently while processing the events from server the client event processing
> (Cache Client Updater) thread will wait for event registrations to finish;
> this will slowdown the event processing and may cause event build of on
> server.
> The code in question:
> {code:java}
> In CacheClientUpdater.processMessage():
> // Wait for the previously failed cache client updater
> // to finish. This will avoid out of order messages.
> waitForFailedUpdater();
> cache.waitForRegisterInterestsInProgress();
> {code}
> We need to see if "waitForInterestRegistration" needs to be done if there is
> no failure in updater thread.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10375) REST management discovery endpoint reports incorrect version
[ https://issues.apache.org/jira/browse/GEODE-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10375: -- Labels: needsTriage (was: ) > REST management discovery endpoint reports incorrect version > > > Key: GEODE-10375 > URL: https://issues.apache.org/jira/browse/GEODE-10375 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage > > prior to GEODE-10312, metadata about the management API url (obtained from > /management) correctly reported /v1/api-docs) > now that we have switched from swagger to springdoc it should now report > /v3/api-docs > see hardcoded value > [here|https://github.com/apache/geode/blob/develop/geode-web-management/src/main/java/org/apache/geode/management/internal/rest/controllers/DocLinksController.java#L38] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (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:all-tabpanel
]
Alexander Murmann updated GEODE-10374:
--
Labels: needsTriage (was: )
> 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: Bug
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: 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] [Updated] (GEODE-10373) CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test run to timeout
[ https://issues.apache.org/jira/browse/GEODE-10373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10373: -- Labels: needsTriage (was: ) > CI Failures: Windows geode-lucene:integrationTest hitting OOM cause CI test > run to timeout > -- > > Key: GEODE-10373 > URL: https://issues.apache.org/jira/browse/GEODE-10373 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > LuceneIndexCommandsWithReindexAllowedIntegrationTest > > whenLuceneReindexingInProgressThenListIndexCommandMustExecuteSuccessfully > FAILED > java.lang.OutOfMemoryError: Java heap space -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10372) CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED
[ https://issues.apache.org/jira/browse/GEODE-10372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10372: -- Labels: needsTriage (was: ) > CI Failures: MicrometerBinderTest.uptimeMetricsBinderExists FAILED > -- > > Key: GEODE-10372 > URL: https://issues.apache.org/jira/browse/GEODE-10372 > Project: Geode > Issue Type: Bug >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.client.ServerOperationException: remote server on > heavy-lifter-880ddf1e-8708-569e-aed8-b02a2ae3d5a6(6388:loner):58892:a17ee644: > Function named CheckIfMeterExistsFunction is not registered to FunctionService > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394) > at > org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234) > at > org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209) > at > org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394) > at > org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45) > at > org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284) > at > org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820) > at > org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368) > at > org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377) > at > org.apache.geode.metrics.MicrometerBinderTest.uptimeMetricsBinderExists(MicrometerBinderTest.java:163) > 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.apache.geode.test.junit.rules.gfsh.GfshRule$1.evaluate(GfshRule.java:75) > at > org.apache.geode.test.junit.rules.FolderRule$1.evaluate(FolderRule.java:54) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at org.junit.runner.JUnitCore.run(JUnitCore.java:115) > at >
[jira] [Updated] (GEODE-10368) New warnings Visual Studio compilation issues
[ https://issues.apache.org/jira/browse/GEODE-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10368: -- Labels: needsTriage (was: ) > New warnings Visual Studio compilation issues > -- > > Key: GEODE-10368 > URL: https://issues.apache.org/jira/browse/GEODE-10368 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > Using later Visual Studio MSVC 19.29.30145.0, two new warnings are being > generated that block compilation of the native client. > nativeclient\cppcache\src\TcrMessage.cpp(3217,12): warning C4101: 'exMsg': > unreferenced local variable > [C:\build\dependencies\nativeclient\cppcache\static\apache-geode-static.vcxproj] > > nativeclient\cppcache\src\ThinClientRedundancyManager.cpp(91,58): warning > C4267: 'argument': conversion from 'size_t' to 'int32_t', possible loss of > data > [C:\build\dependencies\nativeclient\cppcache\static\apache-geode-static.vcxproj] > > Suggested fixes, delete exMsg as unused variable and do a static cast of the > value to int32_t. -- 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 ] Alexander Murmann updated GEODE-10366: -- Labels: needsTriage (was: ) > 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 > Labels: needsTriage > > 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-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10364:
--
Labels: needsTriage (was: )
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: needsTriage
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [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
]
Alexander Murmann updated GEODE-10361:
--
Labels: needsTriage (was: )
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown fails to find any locators
> with NoAvailableLocatorsException
> --
>
> Key: GEODE-10361
> URL: https://issues.apache.org/jira/browse/GEODE-10361
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> AutoConnectionSourceImplIntegrationTest >
> test_DiscoverLocators_whenOneLocatorWasShutdown FAILED
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to
> connect to any locators in the list
> [heavy-lifter-972eb062-9b0f-52e1-a58b-0dd44f11dbcc:27503]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:159)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImplIntegrationTest.test_DiscoverLocators_whenOneLocatorWasShutdown(AutoConnectionSourceImplIntegrationTest.java:317)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-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
]
Alexander Murmann updated GEODE-10360:
--
Labels: needsTriage (was: )
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA fails with timeout because queue doesn't
> drain
> ---
>
> Key: GEODE-10360
> URL: https://issues.apache.org/jira/browse/GEODE-10360
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> ConcurrentParallelGatewaySenderOffHeapDistributedTest >
> testPartitionedParallelPropagationHA FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest$$Lambda$629/0x000800f464d0.run
> in VM 6, Host Host
> heavy-lifter-4ba2a3b0-2fc9-575d-979e-e4170775d5c0.c.apachegeode-ci.internal
> with 8 VMs, Geode 10240.0.0, Java 17
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:688)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:496)
> at
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderDistributedTest.testPartitionedParallelPropagationHA(ConcurrentParallelGatewaySenderDistributedTest.java:656)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
>
[jira] [Updated] (GEODE-10357) add gesterzhou as code owner for logging components
[ https://issues.apache.org/jira/browse/GEODE-10357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10357: -- Labels: needsTriage (was: ) > add gesterzhou as code owner for logging components > --- > > Key: GEODE-10357 > URL: https://issues.apache.org/jira/browse/GEODE-10357 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > I will add myself as code owner for following components. > geode-log4j/** > geode-logging/** > geode-core/**/org/apache/geode/logging/** > geode-core/**/org/apache/geode/internal/logging/** -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10353) Change IndexThresholdSize default value
[
https://issues.apache.org/jira/browse/GEODE-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10353:
--
Labels: needsTriage (was: )
> Change IndexThresholdSize default value
> ---
>
> Key: GEODE-10353
> URL: https://issues.apache.org/jira/browse/GEODE-10353
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> When doing range queries with the wildcard character(%), there are no result.
> The problem is that when we are doing a range query like this:
> {code:java}
> query --query="SELECT e.key, e.value from /example-region.entrySet e
> where e.value.positions['SUN'] LIKE 'abc%'"
> {code}
> The printed results will be null.
> The comparison will be divided into two comparison >='abc' and <'abd'.
> First it checks all entries that are lower than 'abd' and store them in the
> intermediate results. There are all entries which attribute 'SUN' is lower
> than 'abd' which can be a very high number. It iterates through all entries
> and store first 100 entries in the intermediate results. The limit is 100, it
> can be changed if an user sets the indexThresholdSize to higher value when
> starting servers, but in many cases the user couldn't know how many entries
> will be in the region.
> So the best way is to set this indexThresholdSize to Integer.MAX_VALUE by
> default so the query will always give the correct results.
> The limit which is set in query is not the same as this limit, so with this
> change it will still put limit on printing results.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10352) Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10352: -- Labels: needsTriage (was: ) > Update Dockerfile to use Ruby >= 2.6 in the tool to preview Geode > documentation > --- > > Key: GEODE-10352 > URL: https://issues.apache.org/jira/browse/GEODE-10352 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > The script to preview the documentation of Geode (./preview-user-guide.sh) is > not working anymore. > The following error appears while running it (unless you have a previously > downloaded geodedocs/temp docker image in your local docker repo): > ERROR: Error installing elasticsearch: > The last version of faraday (>= 0) to support your Ruby & RubyGems was > 1.10.0. Try installing it with `gem install faraday -v 1.10.0` and then > running the current command again > faraday requires Ruby version >= 2.6. The current ruby version is > 2.5.9.229. > That error prevents the preview script to work. > It is needed to update the docker image used to preview the documentation to > use a Ruby version >= 2.6 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10351) [CI failure] ModifyColocationIntegrationTest > testModifyColocation
[
https://issues.apache.org/jira/browse/GEODE-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10351:
--
Labels: needsTriage (was: )
> [CI failure] ModifyColocationIntegrationTest > testModifyColocation
> ---
>
> Key: GEODE-10351
> URL: https://issues.apache.org/jira/browse/GEODE-10351
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> ModifyColocationIntegrationTest > testModifyColocation FAILED
> java.lang.AssertionError:
> Expecting actual throwable to be an instance of:
> java.lang.IllegalStateException
> but was:
> org.apache.geode.cache.CacheClosedException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed., caused by
> org.apache.geode.cache.DiskAccessException: For DiskStore: disk: A
> DiskAccessException has occurred while writing to the disk for region
> /region3. The region will be closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5221)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3123)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10350) volunteerForPrimary should proceed when being elector or knowing elector
[ https://issues.apache.org/jira/browse/GEODE-10350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10350: -- Labels: needsTriage (was: ) > volunteerForPrimary should proceed when being elector or knowing elector > > > Key: GEODE-10350 > URL: https://issues.apache.org/jira/browse/GEODE-10350 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > Inside BucketAdvisor.volunteerForPrimary(), when current member is elector or > has profile for elector, then current member should proceed to volunteer for > primary bucket. > Current logic happened to be opposite. It might be due to careless code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10349) Client connects to a new server socket should check its availability
[ https://issues.apache.org/jira/browse/GEODE-10349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10349: -- Labels: needsTriage (was: ) > Client connects to a new server socket should check its availability > - > > Key: GEODE-10349 > URL: https://issues.apache.org/jira/browse/GEODE-10349 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > When client connects to a new server (or restarted server), it might > encounter SocketTimeoutException which could take 59 seconds. > To speed up, the idea is to check if the server address's is reachable with > smaller timeout. > If the server's address is not reachable, no need to block waiting for 59 > seconds (DEFAULT_SOCKET_CONNECT_TIMEOUT). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10348) Correct documentation about conflation
[ https://issues.apache.org/jira/browse/GEODE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10348: -- Labels: needsTriage (was: ) > Correct documentation about conflation > -- > > Key: GEODE-10348 > URL: https://issues.apache.org/jira/browse/GEODE-10348 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > The Geode documentation states on conflation: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message assumes the value of the new update and the new update is dropped, as > shown here for key A." > Nevertheless, that is not correct. The actual behavior is the following: > "When an update is added to a queue that has conflation enabled, if there is > already an update message in the queue for the entry key, then the existing > message is dropped and the new update is added to the end of the queue, as > shown here for key A." -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10347) [Refactor] PartitionedRegionStatsDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10347: -- Labels: needsTriage (was: ) > [Refactor] PartitionedRegionStatsDUnitTest > --- > > Key: GEODE-10347 > URL: https://issues.apache.org/jira/browse/GEODE-10347 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > Refactor PartitionedRegionStatsDUnitTest to use the new test framework > Rename PartitionedRegionStatsDUnitTest to > PartitionedRegionStatsDistributedTest -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10346) Correct batch-time-interval description in documentation
[ https://issues.apache.org/jira/browse/GEODE-10346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10346: -- Labels: needsTriage (was: ) > Correct batch-time-interval description in documentation > > > Key: GEODE-10346 > URL: https://issues.apache.org/jira/browse/GEODE-10346 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > The description of the batch-time-interval parameter for the Gateway Sender > in the Geode documentation states the following: > "Maximum amount of time, in ms, that can elapse before a batch is delivered." > Nevertheless, that is not completely true. > The number of ms that can elapse before a batch is delivered could be longer > than what is configured in batch-time-interval in the case that the batch > being created has not yet reached the value of max-batch-size and there are > still events in the gateway sender's queue to be added to the batch. If that > is the case, new events will keep being added to the batch without taking > into account the value for batch-time-interval. > The batch-time-interval parameter is only used when the batch being filled > has not reached the max-batch-size but there are no events in the queue. In > that case, in order not to delay the delivery of the batch until there are > events in the queue, this value is used to determine if the batch must be > sent. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10339) The server fails to start because the .crf of the .drf file is missing
[
https://issues.apache.org/jira/browse/GEODE-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10339:
--
Labels: needsTriage (was: )
> The server fails to start because the .crf of the .drf file is missing
> --
>
> Key: GEODE-10339
> URL: https://issues.apache.org/jira/browse/GEODE-10339
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Priority: Major
> Labels: needsTriage
>
> {color:#0e101a}The server fail with following:{color}
>
> {color:#0e101a}{"timestamp":"2022-05-16T08:25:35.708Z","severity":"error","message":"Cache
> initialization for GemFireCache[id = 776315735; isClosing = false;
> isShutDownAll = false; created = Mon May 16 08:25:33 UTC 2022; server =
> false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed because:
> java.lang.IllegalStateException: {*}The following required files could not be
> found: *.crf files with these ids:
> [33].{*}","metadata":\{"function":"KVDB"},"version":"1.1.0","service_id":"eric-udr-kvdb-ag","extra_data":\{"thread_info":{"thread_name":"main","thread_id":"1"},"e":\{"exception":""}}}{color}
>
> {color:#0e101a}As a last compaction step, the server deletes the compacted
> .crf file. The deletion is done in the following way:{color}
> # {color:#0e101a}Write delete operation (delete ".crf" file) in the ".if"
> file. {color}
> # {color:#0e101a}Delete .crf file{color}
>
> {color:#0e101a}The problem with server startup happens in the following
> scenario:{color}
> # {color:#0e101a}The server writes the delete" operation (for .crf file) in
> the ".if" file. The write is not immediately flushed to the ".if" file, but
> it goes to the async write buffer.{color}
> # {color:#0e101a}The server deletes the ".crf" file.{color}
> # {color:#0e101a}The forceful restart happens before the async write buffer
> is flushed to the ".if" file. This scenario leaves the ".if" file not
> updated, and therefore server startup fails later on.{color}
>
> {color:#0e101a}To avoid the above issue, we can use the existing parameter in
> a geode that forces the server to write synchronously to the ".if"
> file:{color}
>
> {code:java}
> --J=-Dgemfire.syncMetaDataWrites=true
> {code}
>
>
> {color:#0e101a}This parameter is not mentioned anywhere in the documentation.
> So it would be good to add it to the following document:{color}
>
> {color:#0e101a}https://geode.apache.org/docs/guide/114/managing/disk_storage/managing_disk_buffer_flushes.html{color}
>
> {color:#0e101a}Changing this parameter's default value to true would also be
> good. {color}
> {color:#0e101a}This parameter should not affect performance as the ".if" file
> is not updated frequently.{color}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
[
https://issues.apache.org/jira/browse/GEODE-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10338:
--
Labels: needsTriage (was: )
> LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
> --
>
> Key: GEODE-10338
> URL: https://issues.apache.org/jira/browse/GEODE-10338
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
> When stopSession is called on the appender, it closes the ManagerLogWriter's
> files but does not release its reference to it and the LogWriterAppender
> instance is kept around after disconnect. So this ends up keeping the
> InternalDistributedSystem alive.
> To fix this change LogWriterAppender.stopSession like so:
> {code:java}
> public synchronized void stopSession() {
> LOGGER.info("Stopping session in {}.", this);
> if (logWriter == null) {
> // we are probably already paused but make sure we are
> pause();
> return;
> }
> logWriter.shuttingDown();
> pause();
> logWriter.closingLogFile();
> logWriter = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10337) SocketCreatorFactory does not null out instance static
[
https://issues.apache.org/jira/browse/GEODE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10337:
--
Labels: needsTriage (was: )
> SocketCreatorFactory does not null out instance static
> --
>
> Key: GEODE-10337
> URL: https://issues.apache.org/jira/browse/GEODE-10337
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> The SocketCreatorFactory has a static "instance" field that keeps the
> singleton factory. The factory has a reference in "distributionConfig" that
> ends up keeping the InternalDistributedSystem alive after disconnect.
> It also has a static close method but the product never calls it.
> To fix this leak do the following:
> On InternalDistributedSystem.disconnect add to the end of it:
> {code:java}
> if (!attemptingToReconnect) {
> SocketCreatorFactory.close();
> }
> {code}
> Also I think it would be good to change SocketCreatorFactory.getInstance to
> null out the static when close it called like so:
> {code:java}
> private static synchronized SocketCreatorFactory getInstance(boolean
> closing) {
> SocketCreatorFactory result = instance;
> if (result == null && !closing) {
> result = new SocketCreatorFactory();
> instance = result;
> } else if (result != null && closing) {
> instance = null;
> }
> return result;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
[ https://issues.apache.org/jira/browse/GEODE-10336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10336: -- Labels: needsTriage (was: ) > ConnectionTable.close does not null out its static lastInstance field > - > > Key: GEODE-10336 > URL: https://issues.apache.org/jira/browse/GEODE-10336 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The ConnectionTable.close method does a bunch of work but it does not null > out the static "lastInstance" atomic. This causes it to keep the > ConnectionTable alive which ends up keeping the InternalDistributedSystem > alive. > The easiest fix is to do this at the end of close: "emergencyClose();". The > emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
[ https://issues.apache.org/jira/browse/GEODE-10335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10335: -- Labels: needsTriage (was: ) > TXManagerImpl.close does not remove itself from the static singeton > --- > > Key: GEODE-10335 > URL: https://issues.apache.org/jira/browse/GEODE-10335 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > TXManagerImpl.close does not remove itself from the static singleton. This > causes it to keep the GemFireCacheImpl alive after it has been closed. > The simple fix is to add "currentInstance = null" at the end of the close > method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10334) Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and DistributedMulticastRegionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10334: -- Labels: needsTriage (was: ) > Refactor DistributedMulticastRegionWithUDPSecurityDUnitTest and > DistributedMulticastRegionDUnitTest > --- > > Key: GEODE-10334 > URL: https://issues.apache.org/jira/browse/GEODE-10334 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage > > Refactor these tests to remove the deprecated APIs and use the updated test > framework -- This message was sent by Atlassian Jira (v8.20.7#820007)
[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
]
Alexander Murmann updated GEODE-10333:
--
Labels: needsTriage (was: )
> 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
>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)
> 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
]
Alexander Murmann updated GEODE-10332:
--
Labels: needsTriage (was: )
> 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
>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-10331) DistributionImpl.destroyMember keeps cache alive for some number of seconds
[ https://issues.apache.org/jira/browse/GEODE-10331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10331: -- Labels: needsTriage (was: ) > DistributionImpl.destroyMember keeps cache alive for some number of seconds > --- > > Key: GEODE-10331 > URL: https://issues.apache.org/jira/browse/GEODE-10331 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > org.apache.geode.distributed.internal.DistributionImpl.destroyMember creates > a thread that will hold onto the DIstributesSystem/Cache through the > DirectChannel it has for 3 seconds by default. It could be even longer if > p2p.disconnectDelay is set to a value > 3000. > This can be a problem if the JVM is trying to reconnect since this old cache > uses memory. > Instead of creating a new thread for every call of destroyMember, we should > just have a single ScheduledExecutor that we schedule the background > "closeEndpoint" with. > Also since all this code interacts with the DirectChannel all the logic about > the executor and scheduling it should belong to DirectChannel, not the > DistributionImpl. > When the DirectChannel has disconnect called on it, then it should get rid of > all the tasks scheduled in the executor since they are no longer needed. > I think this issue has been around for a long time because the creation of > the thread refers to fixing "Bug 37944" which is on old bug system that is > not longer used for geode. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10330) Resource issues lead to "MemberDisconnectedException: Member isn't responding to heartbeat requests"
[
https://issues.apache.org/jira/browse/GEODE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10330:
--
Labels: needsTriage (was: )
> Resource issues lead to "MemberDisconnectedException: Member isn't responding
> to heartbeat requests"
>
>
> Key: GEODE-10330
> URL: https://issues.apache.org/jira/browse/GEODE-10330
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> A failure was observed in
> DistributedMulticastRegionWithUDPSecurityDUnitTest >
> testMulticastAfterReconnect due to suspect strings with fatal-level logging
> of "Membership service failure: Member isn't responding to heartbeat
> requests".
> Investigating the logs showed all members reporting long statistics sampling
> wakeup delays, indicating resource issues:
>
> {code:java}
> [vm3] [warn 2022/05/21 07:28:16.251 UTC LocatorWithMcast
> tid=0xb8] Statistics sampling thread detected a wakeup delay of 4760 ms,
> indicating a possible resource issue. Check the GC, memory, and CPU
> statistics.
> ...
> [locator] [warn 2022/05/21 07:28:20.288 UTC tid=0x3b]
> Statistics sampling thread detected a wakeup delay of 12400 ms, indicating a
> possible resource issue. Check the GC, memory, and CPU statistics.
> ...
> [vm1] [warn 2022/05/21 07:28:20.969 UTC vm1 tid=0xda]
> Statistics sampling thread detected a wakeup delay of 13738 ms, indicating a
> possible resource issue. Check the GC, memory, and CPU statistics.
> ...
> [vm0] [warn 2022/05/21 07:28:22.226 UTC vm0 tid=0xa9]
> Statistics sampling thread detected a wakeup delay of 15110 ms, indicating a
> possible resource issue. Check the GC, memory, and CPU statistics. {code}
> Using the progress tool from the dev-tools directory in the Geode repository,
> the following tests were found to be running during the resource issues,
> possibly indicating that one or more of them are particularly
> resource-intensive:
> {noformat}
> $> progress -r '2022-05-21 07:28:16.251 -' | grep org | sort{noformat}
> {code:java}
> org.apache.geode.cache.PRCacheListenerWithInterestPolicyAllDistributedTest.afterUpdateIsInvokedInEveryMember[0:
> redundancy=0]
> org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest.recreateIndexWithDifferentFieldsShouldFail(PARTITION_OVERFLOW_TO_DISK)
> [2]
> org.apache.geode.cache.query.cq.dunit.CqDataUsingPoolOptimizedExecuteDUnitTest.testCQHAWithState
>
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testPartitionedCqOnAccessorBridgeServer
> org.apache.geode.cache30.CallbackArgDUnitTest.testForCA
> org.apache.geode.cache30.DistributedMulticastRegionWithUDPSecurityDUnitTest.testMulticastAfterReconnect
>
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testDistributedInvalidate
> org.apache.geode.cache30.GlobalRegionOffHeapDUnitTest.testOrderedUpdates
> org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown
>
> org.apache.geode.distributed.internal.P2PMessagingConcurrencyDUnitTest.testP2PMessaging(true,
> false, 32768, 65536) [6]
> org.apache.geode.disttx.PRDistTXDUnitTest.testSimulaneousChildRegionCreation
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest.testClientCommitFunctionWithFailure
>
> org.apache.geode.internal.cache.eviction.OffHeapEvictionStatsDUnitTest.testHeapLruCounter
>
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOperation_1_DUnitTest.testParallelPropagationSenderStartAfterStopOnAccessorNode
>
> org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDistributedTest.testParallelGatewaySenderStartOnAccessorNode
>
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagation_PartitionedRegionDUnitTest.testPartitionedSerialPropagationHA
> org.apache.geode.internal.tcp.TCPConduitDUnitTest.basicAcceptConnection[0]
> org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest.importFailWithExistingRegion
>
> org.apache.geode.rest.internal.web.controllers.RestAPIsOnGroupsFunctionExecutionDUnitTest.testBasicP2PFunctionSelectedGroup[1]
>
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.failureShouldStillAllowOtherContainersDataAccess
>
> org.apache.geode.session.tests.Tomcat8ClientServerCustomCacheXmlTest.containersShouldExpireInSetTimeframe
> org.apache.geode.session.tests.Tomcat8Test.containersShouldReplicateCookies
> org.apache.geode.session.tests.Tomcat9ClientServerTest.invalidationShouldRemoveValueAccessForAllContainers
> {code}
> Future failures due to this sort of resource issue should also list
> concurrently running tests so that
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10329:
--
Labels: needsTriage (was: )
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss
> --
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> 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)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> 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 junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> 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
[jira] [Updated] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
[ https://issues.apache.org/jira/browse/GEODE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10328: -- Labels: needsTriage (was: ) > Cache close with partitioned regions does not close all the region's > statistics > --- > > Key: GEODE-10328 > URL: https://issues.apache.org/jira/browse/GEODE-10328 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > I noticed when looking at hprof memory dumps of a JVM whose cache had been > closed that something was keeping the PartitionedRegion instances from being > garbage collected. It turns out that the region's RegionPerfStats instance > was not closed. Other stats for the region were closed but not the one owned > by PartitionedRegionDataStore's bucketStats instance variable. This > indicates that the PartitionedRegionDataStore.cleanUp method is not being > called. > It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a > code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT > without calling "closePartitionedRegion" which invokes "dataStore.cleanup". > This buggy code path has its reasons for not calling closePartitionedRegion. > To fix this bug it would be easy and safe to have this code path call > dataStore.getCachePerfStats().close() -- 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 ] Alexander Murmann updated GEODE-10327: -- Labels: needsTriage (was: ) > 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 >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] [Updated] (GEODE-10325) Benchmarks fail with UnmarshalException caused by EOFException
[
https://issues.apache.org/jira/browse/GEODE-10325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10325:
--
Labels: needsTriage (was: )
> Benchmarks fail with UnmarshalException caused by EOFException
> --
>
> Key: GEODE-10325
> URL: https://issues.apache.org/jira/browse/GEODE-10325
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.3, 1.14.4, 1.14.5, 1.15.0
>Reporter: Hale Bales
>Priority: Major
> Labels: needsTriage
>
> This is a blanket ticket for all benchmark failures due to this cause. It
> will be cleaner to track here than the tickets for individual tests.
> The failure has the following stack trace and has been occurring for a long
> time.
> {code:java}
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:98)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:96)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10324) [CI Failure] ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter
[
https://issues.apache.org/jira/browse/GEODE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10324:
--
Labels: needsTriage (was: )
> [CI Failure] ExportLogsOverHttpDistributedTest >
> testExportWithExactLogLevelFilter
> --
>
> Key: GEODE-10324
> URL: https://issues.apache.org/jira/browse/GEODE-10324
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> > Task :geode-web:distributedTest
> ExportLogsOverHttpDistributedTest > testExportWithExactLogLevelFilter FAILED
> java.lang.AssertionError:
> Expected size: 3 but was: 2 in:
>
> [C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\locator-0,
>
> C:\\Users\\geode\\AppData\\Local\\Temp\\junit3661184760048034890\\unzippedLogs\\server-2]
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.verifyZipFileContents(ExportLogsDistributedTestBase.java:283)
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsDistributedTestBase.testExportWithExactLogLevelFilter(ExportLogsDistributedTestBase.java:227)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
>
[jira] [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
]
Alexander Murmann updated GEODE-10323:
--
Labels: needsTriage (was: )
> 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 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-10319) Stopping the metrics service does not delete its meters
[
https://issues.apache.org/jira/browse/GEODE-10319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10319:
--
Labels: needsTriage (was: )
> Stopping the metrics service does not delete its meters
> ---
>
> Key: GEODE-10319
> URL: https://issues.apache.org/jira/browse/GEODE-10319
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> Some of Geode's standard meters hold references the cache.
> {{InternalDistributedSystemMetricsService.clearAndCloseMeterRegistry()}}
> closes the meter registry without deleting its meters. As a result, the
> closed registry retains indirect references to the cache, holding the closed
> cache in memory.
> {{clearAndCloseMeterRegistry()}} should clear the registry in addition to
> closing it.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10318) locators property is unexpectedly being modified in InternalLocator
[
https://issues.apache.org/jira/browse/GEODE-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10318:
--
Labels: needsTriage (was: )
> locators property is unexpectedly being modified in InternalLocator
> ---
>
> Key: GEODE-10318
> URL: https://issues.apache.org/jira/browse/GEODE-10318
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Jinmei Liao
>Priority: Major
> Labels: needsTriage
>
> if a locator is started with existing "locators" attributes that points to
> itself using ip address, ie.
> {code:java}
> locators=192.168.0.15[22348]
> {code}
> if the machine has a hostname specified in its host file
> {code:java}
> 192.168.0.15 abc-a01
> {code}
> Then after the locator is started, the log banner would show duplicate
> entries in the locators attributes:
> {code:java}
> locators=192.168.0.15[22348],abc-a01[22348]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10317: -- Labels: needsTriage (was: ) > Range query with wildcard character(%) doing wrong comparison > - > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10315: -- Labels: needsTriage (was: ) > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9394) Apache Geode does not properly cleanup its SSL context between runs
[
https://issues.apache.org/jira/browse/GEODE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537826#comment-17537826
]
Alexander Murmann commented on GEODE-9394:
--
[~jblum] Sorry, to follow up after such a long time. Do you recall what you did
to run into this issue? Also, when you say "retained between Geode instance
runs", I think you mean server restarts. However, you prose that somehow our
statics are causing this, but those of course don't persists between restarts.
What's the "instance runs" you are referring to?
> Apache Geode does not properly cleanup its SSL context between runs
> ---
>
> Key: GEODE-9394
> URL: https://issues.apache.org/jira/browse/GEODE-9394
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: John Blum
>Priority: Critical
>
> Because Geode internally uses may statics to maintain state and to pass
> configuration between components in a non-Object Oriented fashion, I believe
> stale SSL configuration is being retained between Geode instance runs,
> leading to Exceptions thrown of the following nature:
> {code}
> Caused by: org.apache.geode.GemFireConfigException: Error configuring GemFire
> ssl
> at
> org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:249)
> at
> org.apache.geode.internal.net.SocketCreator.(SocketCreator.java:180)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.createSSLSocketCreator(SocketCreatorFactory.java:114)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSSLSocketCreator(SocketCreatorFactory.java:88)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getOrCreateSocketCreatorForSSLEnabledComponent(SocketCreatorFactory.java:104)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSocketCreatorForComponent(SocketCreatorFactory.java:74)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.(ConnectionFactoryImpl.java:84)
> at
> org.apache.geode.cache.client.internal.PoolImpl.(PoolImpl.java:261)
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:161)
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:374)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2835)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getDefaultPool(GemFireCacheImpl.java:1321)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.getDefaultPool(ClientRegionFactoryImpl.java:101)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.createRegionAttributes(ClientRegionFactoryImpl.java:249)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.create(ClientRegionFactoryImpl.java:232)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.newRegion(ClientRegionFactoryBean.java:193)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.createRegion(ClientRegionFactoryBean.java:164)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.newClientRegion(CacheTypeAwareRegionFactoryBean.java:181)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.createRegion(CacheTypeAwareRegionFactoryBean.java:141)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1858)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1795)
> ... 69 more
> Caused by: java.security.UnrecoverableKeyException: Password must not be null
> at
> sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:134)
> at
> sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57)
> at
> sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71)
> at java.security.KeyStore.getKey(KeyStore.java:1023)
> at
> sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:145)
> at
> sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> at
>
[jira] [Updated] (GEODE-10314) [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10314:
--
Labels: needsTriage (was: )
> [CI Failure] TxCommitMessageBCOldClientToServerTxBothTest > test[1] FAILED
> --
>
> Key: GEODE-10314
> URL: https://issues.apache.org/jira/browse/GEODE-10314
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxBothTest
> > test[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$60/174734073.run
> in VM 4 running on Host 7b66f9a900ce with 5 VMs
> Caused by:
> org.apache.geode.SystemConnectException: Unable to join the
> distributed system in 67530ms{noformat}
>
> {noformat}
> 384 tests completed, 1 failed, 24 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-results/upgradeTest/1652478284/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.10-build.0393/test-artifacts/1652478284/upgradetestfiles-openjdk8-1.12.10-build.0393.tgz{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10312:
--
Labels: blocks-1.15.0 (was: blocks-1.15.0 needsTriage)
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Labels: blocks-1.15.0
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> ---
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
>
[jira] [Updated] (GEODE-10312) Remove SpringBootApplication In SwaggerConfig
[
https://issues.apache.org/jira/browse/GEODE-10312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10312:
--
Labels: needsTriage (was: )
> Remove SpringBootApplication In SwaggerConfig
> -
>
> Key: GEODE-10312
> URL: https://issues.apache.org/jira/browse/GEODE-10312
> Project: Geode
> Issue Type: Bug
> Components: locator, rest (admin), rest (dev)
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Labels: needsTriage
> Attachments: GEODE-10312.zip
>
>
> The issue was introduced by GEODE-10282. As part of commit
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4],
> {{SwaggerConfig}} classes used to start and configure the internal
> {{geode-web-management}} and {{geode-web-api}} services use the
> {{@SpringBootApplication}} annotation. This annotation automatically enables
> other spring annotations (like {{@EnableAutoConfiguration}} and
> {{@ComponentScan}}) which, in turn, might cause critical issues during
> startup as {{spring}} tries to automatically configure several services based
> on classes and interfaces found within the member's class path.
> I'm attaching a small scenario that reproduces the problem; the
> {{reproduce.sh}} script simply starts a locator making sure that the
> {{spring-jdbc-5.3.20.jar}} is part of the class path. When using any commit
> after
> [41305de1405c2125142e6b337c3f1704f736fca4|https://github.com/apache/geode/commit/41305de1405c2125142e6b337c3f1704f736fca4]
> the logs will contain the following:
> {noformat}
> [info 2022/05/16 15:54:38.997 IST locator0 tid=0x1] Adding webapp
> /management
> [info 2022/05/16 15:54:39.610 IST locator0 tid=0x1] Initializing
> Servlet 'management'
> [info 2022/05/16 15:54:42.124 IST locator0 tid=0x1] Will secure any
> request with
> [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@33ed6546,
>
> org.springframework.security.web.context.SecurityContextPersistenceFilter@5a503cf0,
> org.springframework.security.web.header.HeaderWriterFilter@5b04224a,
> org.springframework.security.web.authentication.logout.LogoutFilter@17db90a7,
> org.springframework.security.web.savedrequest.RequestCacheAwareFilter@6f78c132,
>
> org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@42f9b425,
>
> org.springframework.security.web.authentication.AnonymousAuthenticationFilter@54d62c35,
> org.springframework.security.web.session.SessionManagementFilter@78907a46,
> org.springframework.security.web.access.ExceptionTranslationFilter@eaf3dd0,
> org.springframework.security.web.access.intercept.FilterSecurityInterceptor@7cd6b76a]
> [warn 2022/05/16 15:54:42.975 IST locator0 tid=0x1] Exception
> encountered during context initialization - cancelling refresh attempt:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> [error 2022/05/16 15:54:42.980 IST locator0 tid=0x1] Context
> initialization failed
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'dataSource' defined in class path resource
> [org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]:
> Unsatisfied dependency expressed through method 'dataSource' parameter 0;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name
> 'spring.datasource-org.springframework.boot.autoconfigure.jdbc.DataSourceProperties':
> Invocation of init method failed; nested exception is
> java.lang.NoClassDefFoundError: org/springframework/dao/DataAccessException
> at
> org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:800)
> at
> org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:541)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1352)
> at
>
[jira] [Updated] (GEODE-10311) Intermittent CI failure in AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
[
https://issues.apache.org/jira/browse/GEODE-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10311:
--
Labels: needsTriage (was: )
> Intermittent CI failure in
> AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient
> --
>
> Key: GEODE-10311
> URL: https://issues.apache.org/jira/browse/GEODE-10311
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> AuthExpirationBackwardCompatibleDUnitTest >
> registeredInterest_FailedReAuth_non_durableClient fails intermittently. I do
> not know whether this is a test problem or a product problem.
> I first saw the failure in a precheckin test run on JDK17:
> * [https://concourse.apachegeode-ci.info/builds/52805744]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-results/upgradeTest/1652409122/]
> * Test artifacts:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7686/test-artifacts/1652409122/upgradetestfiles-geode-pr-7686.tgz]
> The failure also happens on the {{develop}} branch, which does not yet have
> my PR changes. The failure occured 3 times in 100 executions of this test
> method on JDK11.
> Stack trace (from my PR precheckin):
> {noformat}
> java.lang.AssertionError:
> Expecting empty but was:
> [CacheClientProxy[identity(heavy-lifter-7d403877-c6e7-5ba6-80ed-0c1ed553c05a(117190:loner):42300:114bc2ba,connection=1;
> port=42332; primary=true; version=GEODE 1.15.0]]
> at
> org.apache.geode.security.AuthExpirationBackwardCompatibleDUnitTest.registeredInterest_FailedReAuth_non_durableClient(AuthExpirationBackwardCompatibleDUnitTest.java:653)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
>
[jira] [Updated] (GEODE-10308) CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
[
https://issues.apache.org/jira/browse/GEODE-10308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10308:
--
Labels: needsTriage (was: )
> CI Failure: Tomcat8SessionsClientServerDUnitTest.testSessionExpiration1 failed
> --
>
> Key: GEODE-10308
> URL: https://issues.apache.org/jira/browse/GEODE-10308
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.cache.CacheClosedException: The cache is closed.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5207)
> at
> org.apache.geode.internal.cache.LocalRegion$Stopper.generateCancelledException(LocalRegion.java:11342)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:87)
> at
> org.apache.geode.internal.cache.execute.InternalFunctionExecutionServiceImpl.onRegion(InternalFunctionExecutionServiceImpl.java:122)
> at
> org.apache.geode.cache.execute.FunctionService.onRegion(FunctionService.java:79)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.getExecutionForFunctionOnRegionWithFilter(ClientServerSessionCache.java:283)
> at
> org.apache.geode.modules.session.catalina.ClientServerSessionCache.touchSessions(ClientServerSessionCache.java:101)
> at
> org.apache.geode.modules.session.catalina.DeltaSessionManager$1.run(DeltaSessionManager.java:534)
> at java.util.TimerThread.mainLoop(Timer.java:556)
> at java.util.TimerThread.run(Timer.java:506)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/334
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10306) CacheServerImpl should stop the acceptor immediately after stop is called
[
https://issues.apache.org/jira/browse/GEODE-10306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10306:
--
Labels: needsTriage (was: )
> CacheServerImpl should stop the acceptor immediately after stop is called
> -
>
> Key: GEODE-10306
> URL: https://issues.apache.org/jira/browse/GEODE-10306
> Project: Geode
> Issue Type: Bug
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> Currently, after cache server stop is called, it takes a while for the
> acceptor to stop taking new data, which can be a problem because the bigger
> the window of time, the greater the risk of data loss.
>
> {noformat}
> public synchronized void stop() {
> if (!isRunning()) {
> return;
> }
> RuntimeException firstException = null;
> try {
> if (loadMonitor != null) {
> loadMonitor.stop();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing load monitor", e);
> firstException = e;
> }
> try {
> if (advisor != null) {
> advisor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing advisor", e);
> firstException = e;
> }
> PROBLEM -> try {
> if (acceptor != null) {
> acceptor.close();
> }
> } catch (RuntimeException e) {
> logger.warn("CacheServer - Error closing acceptor monitor", e);
> if (firstException != null) {
> firstException = e;
> }
> } {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10305) CI Failure: TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest failed
[
https://issues.apache.org/jira/browse/GEODE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10305:
--
Labels: needsTriage (was: )
> CI Failure:
> TomcatSessionBackwardsCompatibilityTomcat8WithOldModulesMixedWithCurrentCanDoPutFromOldModuleTest
> failed
> -
>
> Key: GEODE-10305
> URL: https://issues.apache.org/jira/browse/GEODE-10305
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError: [The Cache Server process
> terminated unexpectedly with exit status 1. Please refer to the log file in
> /tmp/junit439159077415808630/server for full details.
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/tmp/geode_container_install8549633813411705254/cargo_containers/Tomcat8AndCurrentModules/tomcat-8.5.66/apache-tomcat-8.5.66/lib/slf4j-jdk14-1.7.32.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/log4j-slf4j-impl-2.17.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.JDK14LoggerFactory]
> {noformat}
> This is caused by ForcedDisconnectException during cache creation.
> {noformat}
> Exception in thread "main"
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-e2fd6dd2-c530-54ef-ab7c-b95e0e8cca34(server:240126):41036
> started at Thu May 05 21:36:30 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:2899)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1183)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5201)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceImpl.(CqServiceImpl.java:166)
> at
> org.apache.geode.cache.query.cq.internal.CqServiceFactoryImpl.create(CqServiceFactoryImpl.java:59)
> at
> org.apache.geode.cache.query.internal.cq.CqServiceProvider.create(CqServiceProvider.java:63)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:1004)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:864)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:187)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:913)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:814)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:740)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:259)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl$LifecycleListenerImpl.forcedDisconnect(DistributionImpl.java:941)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1792)
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Artifacts can be found here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/331
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10304) CI Failure: ReconnectDUnitTest.testReconnectALocator
[
https://issues.apache.org/jira/browse/GEODE-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10304:
--
Labels: needsTriage (was: )
> CI Failure: ReconnectDUnitTest.testReconnectALocator
>
>
> Key: GEODE-10304
> URL: https://issues.apache.org/jira/browse/GEODE-10304
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ReconnectDUnitTest$14.run in VM 0 running on Host
> heavy-lifter-2ef8f049-b612-51d7-862a-3722e231b1de.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:676)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.assertGfshWaitingThreadAlive(ReconnectDUnitTest.java:646)
> at
> org.apache.geode.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:587)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Updated] (GEODE-10303) CI Failure: MemberMXBeanDistributedTest.testBucketCount failed due to insufficient memory
[
https://issues.apache.org/jira/browse/GEODE-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10303:
--
Labels: needsTriage (was: )
> CI Failure: MemberMXBeanDistributedTest.testBucketCount failed due to
> insufficient memory
> -
>
> Key: GEODE-10303
> URL: https://issues.apache.org/jira/browse/GEODE-10303
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.MemberMXBeanDistributedTest$$Lambda$354/1215689932.run
> in VM 1 running on Host
> heavy-lifter-7c5d091b-f00d-537f-882b-ff4e244a22ad.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:680)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:483)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:80)
> 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.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.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:45)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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] [Updated] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.
[ https://issues.apache.org/jira/browse/GEODE-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10301: -- Labels: blocks-1.15.0 (was: ) > Allow users to have java.time.* types (like LocalDateTime, LocalDate, and > LocalTime) in their query result fields. > --- > > Key: GEODE-10301 > URL: https://issues.apache.org/jira/browse/GEODE-10301 > Project: Geode > Issue Type: Improvement >Reporter: John Martin >Priority: Major > Labels: blocks-1.15.0 > > Users with java.time.* types (like LocalDateTime, LocalDate, and LocalTime) > in their query result fields will need to have, *jackson-datatype-jsr310* > and/or *jackson-datatype-joda* in the runtime classpath to have the proper > formatting. This currently requires users to manually add these classes. > > To improve the user experience we should include these in the release. We > should match the version of jackson-core that we release with. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10300) C++ Native client messages coming from the locator cannot be longer than 3000 bytes
[ https://issues.apache.org/jira/browse/GEODE-10300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10300: -- Labels: needsTriage (was: ) > C++ Native client messages coming from the locator cannot be longer than 3000 > bytes > --- > > Key: GEODE-10300 > URL: https://issues.apache.org/jira/browse/GEODE-10300 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Priority: Major > Labels: needsTriage > > If a locator sends a response to the C++ native client that is longer than > 3000 bytes the C++ native client library will only pass to the client the > first 3000 bytes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10298) [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest > testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
[
https://issues.apache.org/jira/browse/GEODE-10298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10298:
--
Labels: needsTriage (was: )
> [CI Failure] GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> -
>
> Key: GEODE-10298
> URL: https://issues.apache.org/jira/browse/GEODE-10298
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> GatewayReceiverAutoConnectionSourceDUnitTest >
> testBridgeServerAndGatewayReceiverClientAndServerWithGroup FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 417
> [fatal 2022/05/10 18:57:14.216 UTC tid=226]
> Exception in processing request from 10.0.2.167
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:552)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:499)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:482)
> 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.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> 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
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10297:
--
Labels: needsTriage (was: )
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10296) Parser error in HDR histogram log can result in terminate of JVM
[ https://issues.apache.org/jira/browse/GEODE-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10296: -- Labels: needsTriage (was: ) > Parser error in HDR histogram log can result in terminate of JVM > > > Key: GEODE-10296 > URL: https://issues.apache.org/jira/browse/GEODE-10296 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage > > The HDR histogram parser exits the JVM on parsing errors. This results in > benchmarks failing even if the parser error is later recoverable. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10294) Need to consider invalid token when comparing value during putIfAbsent
[ https://issues.apache.org/jira/browse/GEODE-10294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10294: -- Labels: needsTriage (was: ) > Need to consider invalid token when comparing value during putIfAbsent > -- > > Key: GEODE-10294 > URL: https://issues.apache.org/jira/browse/GEODE-10294 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > During retry of putIfAbsent, there is a possibility that value has been > created by the initial operation. Geode treats this as a successful > operation, so that client initiated the operation will also create the entry > in its local cache. However, putIfAbsent of null is a special case, as an > Invalid Token is created instead of null value being put into the region > entry. Need to handle this special case for above value comparison. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10290: -- Labels: needsTriage (was: ) > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10287: -- Labels: needsTriage (was: ) > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
[
https://issues.apache.org/jira/browse/GEODE-10286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10286:
--
Labels: needsTriage (was: )
> cache close in response to a forced disconnect with persistent regions may
> skip some cleanup
> -
>
> Key: GEODE-10286
> URL: https://issues.apache.org/jira/browse/GEODE-10286
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> During a cache close, persistent regions may not cleanup as much as they
> should. This is because when the PersistentAdvisor is closed, CancelException
> is not handled causing other parts of the close to be skipped. I think the
> place to handle it is:
> DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
> is an exception showing what it looks like when this happens:
> {noformat}
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
> egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
> 2022: Member isn't responding to heartbeat requests, caused by org.apac
> he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
> requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
> 3)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
> at
> org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
> at
> org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
> at
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
> at
> org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
> at
> org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
> at
> org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
> at
> org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
> ... 3
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution casuse inconsistency between to sites
[ https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10281: -- Labels: needsTriage (was: ) > Internal conflict replicated region resolution casuse inconsistency between > to sites > > > Key: GEODE-10281 > URL: https://issues.apache.org/jira/browse/GEODE-10281 > Project: Geode > Issue Type: Bug >Reporter: Jakov Varenina >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.7#820007)
