[
https://issues.apache.org/jira/browse/GEODE-10482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinwoo Hwang updated GEODE-10482:
---------------------------------
Summary: Enhance Backward Compatibility Testing for Java 17 Server with
Legacy Clients (was: Enhance Backward Compatibility Suite for Java 17 Server)
> Enhance Backward Compatibility Testing for Java 17 Server with Legacy Clients
> -----------------------------------------------------------------------------
>
> Key: GEODE-10482
> URL: https://issues.apache.org/jira/browse/GEODE-10482
> Project: Geode
> Issue Type: Improvement
> Reporter: Jinwoo Hwang
> Priority: Major
>
> h2. *Summary*
> This epic covers the work required to enhance and certify our backward
> compatibility test suite to validate that Apache Geode servers running on
> *Java 17* can seamlessly communicate with older Geode clients running on
> {*}Java 8 and 11{*}. This is a critical release gate for the Java 17
> migration project (GEODE-10465).
> ----
> h2. *Description*
> h3. *Background*
> The migration of the Geode server to Java 17 introduces a potential
> compatibility risk for our users who may continue to run their clients on
> older, LTS versions of Java like 8 or 11. While Geode's client-server
> protocol is designed to be platform-agnostic, we must empirically validate
> this assumption to prevent breaking production deployments.
> The existing geode-old-client-support and geode-old-versions modules provide
> the foundation for this testing, but they must be enhanced to run in a
> multi-JVM, cross-version matrix.
> h3. *Problem Statement*
> Without explicit cross-JVM compatibility validation, we risk:
> * Breaking production client applications during server upgrades
> * Silent failures in serialization/deserialization between JVMs
> * Authentication/SSL handshake issues due to different default cipher suites
> * Loss of enterprise customer confidence in upgrade safety
> h3. *Business Justification*
> A robust backward compatibility guarantee is a cornerstone of enterprise
> software. This work directly supports our users by de-risking their upgrade
> path, allowing them to adopt new server features without being forced into a
> "big bang" client-side upgrade. It is a mandatory prerequisite for releasing
> the Java 17 version of Geode.
> ----
> h2. *Acceptance Criteria*
> * A new, automated test suite runs successfully in the CI/CD pipeline.
> * The test suite validates a Java 17 Geode server against clients running
> on at least Java 8 and Java 11.
> * The suite tests against a matrix of the last {{N}} supported minor
> versions of Geode clients (e.g., 1.15.x, 1.14.x).
> * Core functionalities (see "Test Scenarios" below) pass without regression.
> * A compatibility matrix is generated and published as part of the official
> release documentation.
> * The test suite is integrated as a release-gating check.
> ----
> h2. *Technical Implementation Plan*
> *1. Enhance Test Infrastructure:*
> * Utilize containerization (Docker) to create a test environment with
> multiple, specific JDK installations (8, 11, 17).
> * Update the Gradle build scripts for geode-old-client-support and
> geode-old-versions to accept JVM version as a parameter for launching client
> processes.
> *2. Create a CI/CD Compatibility Matrix Job:*
> * In GitHub Actions, create a new workflow with a test matrix:
> ** {{{}server_jvm{}}}: {{[17]}}
> ** {{{}client_jvm{}}}: {{[8, 11]}}
> ** {{{}client_geode_version{}}}: {{[<current>, 1.15.x, 1.14.x]}}
> (configurable)
> * This job will execute the enhanced compatibility test suite.
> *3. Implement Focused Test Scenarios:* The suite will be expanded to cover
> high-risk interaction points between different JVMs:
> * *Handshake & Security:* Client-server connection, authentication, and
> SSL/TLS negotiation (critical due to different default ciphers between JDK 8
> and 17).
> * *Serialization:* Full round-trip validation of PDX and
> {{DataSerializable}} objects between the different JVMs.
> * *Core API:* put, get, {{{}remove{}}}, {{query}} (OQL), region
> creation/destruction.
> * *Advanced Features:* Continuous Query (CQ) registration and event
> delivery, Function Execution, transaction boundaries.
> * *Rolling Upgrades:* Simulate a mixed-JVM cluster during a rolling upgrade
> to ensure clients can failover between servers on different Java versions.
> ----
> h2. *Subtasks*
> h3. *Phase 1: Infrastructure & Scaffolding*
> * *GEODE-XXXX-1:* Create Docker images with pre-installed JDK 8, 11, and 17.
> * *GEODE-XXXX-2:* Parameterize the test runner in geode-old-client-support
> to launch clients with a specified JDK.
> * *GEODE-XXXX-3:* Set up the initial GitHub Actions workflow with the test
> matrix axes.
> h3. *Phase 2: Test Implementation*
> * *GEODE-XXXX-4:* Implement the Handshake & Security test suite.
> * *GEODE-XXXX-5:* Implement the cross-JVM Serialization test suite.
> * *GEODE-XXXX-6:* Adapt existing dunit tests for core API validation to run
> within the new matrix.
> * *GEODE-XXXX-7:* Implement tests for CQs and Function Execution.
> h3. *Phase 3: Integration & Documentation*
> * *GEODE-XXXX-8:* Integrate the new test suite as a required check for
> releases.
> * *GEODE-XXXX-9:* Generate and publish the official compatibility matrix in
> the project documentation.
> * *GEODE-XXXX-10:* Update the "Upgrading" documentation with guidance for
> mixed-JVM environments.
> ----
> h2. *Dependencies*
> * *Blocked By:* {{GEODE-10465}} (Core Java 17 Migration) must be
> functionally complete.
> * *Blocks:* The final release of the first Java 17-based version of Apache
> Geode.
> ----
> h2. *Timeline*
> * *Estimated Effort:* 4 Sprints (8 weeks)
> * *Target Completion:* Prior to the first RC for Geode 2.0.0.
> ----
> h2. *Definition of Done*
> * The compatibility test suite is fully automated and integrated into the
> CI/CD pipeline.
> * All defined test scenarios pass for all configurations in the
> compatibility matrix.
> * A clear, public-facing compatibility matrix is published.
> * The suite is a mandatory, passing check for all future releases.
> * The project team has a clear process for diagnosing and fixing any future
> backward-compatibility regressions caught by the suite.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
