Skip to content

chore(spanner): migrate grpc-gcp into google-cloud-java#13184

Open
rahul2393 wants to merge 193 commits into
googleapis:mainfrom
rahul2393:migrate-grpc-gcp-java
Open

chore(spanner): migrate grpc-gcp into google-cloud-java#13184
rahul2393 wants to merge 193 commits into
googleapis:mainfrom
rahul2393:migrate-grpc-gcp-java

Conversation

@rahul2393
Copy link
Copy Markdown
Contributor

@rahul2393 rahul2393 commented May 13, 2026

Summary

Migrate grpc-gcp from GoogleCloudPlatform/grpc-gcp-java/grpc-gcp into google-cloud-java/grpc-gcp as a top-level base Maven module with existing com.google.cloud:grpc-gcp coordinates.

What changed

  • Imported grpc-gcp source under root grpc-gcp.
  • Added grpc-gcp to root Maven reactor.
  • Kept google-cloud-spanner depending on com.google.cloud:grpc-gcp, avoiding duplicate classes in google-cloud-spanner.
  • Added Release Please version marker for next grpc-gcp version 1.11.0-SNAPSHOT.
  • Updated sdk-platform-java/java-shared-dependencies/first-party-dependencies to manage grpc-gcp at 1.11.0-SNAPSHOT.
  • Kept grpc-gcp dependency management self-contained to avoid circular dependency:
    • grpc-gcp does not import google-cloud-shared-dependencies.
    • google-cloud-shared-dependencies can continue managing grpc-gcp through first-party-dependencies.
  • Updated CI package filters so grpc-gcp runs as its own package and still triggers Spanner checks when changed.
  • Excluded live integration tests from default grpc-gcp test compilation.
  • Stabilized GcpManagedChannelTest.testLogMetrics.
  • Added Java 8-only exclusion for Spanner native-image sources because current GraalVM nativeimage artifact requires Java 11 bytecode.

Validation

  • mvn -q -pl grpc-gcp test -Pquick-build
  • cd grpc-gcp && mvn -q dependency:analyze -DfailOnWarning=true -DskipTests -Pquick-build
  • mvn -q -pl java-spanner/google-cloud-spanner -am -DskipTests compile -Pquick-build
  • cd java-spanner && mvn -q dependency:analyze -Pquick-build -DfailOnWarning=true -Dmdep.analyze.skip=false
  • ./generation/check_non_release_please_versions.sh

@rahul2393 rahul2393 marked this pull request as ready for review May 13, 2026 15:25
@rahul2393 rahul2393 requested review from a team as code owners May 13, 2026 15:25
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces the grpc-gcp library into the google-cloud-java monorepo, including its core implementation for gRPC channel pooling, affinity management, and multi-endpoint support, along with necessary configuration updates in pom.xml and versions.txt. My review identified two potential resource management issues: the use of an unbounded CachedThreadPool for state notifications, which could lead to thread exhaustion, and the static SHARED_BACKGROUND_SERVICE executor, which lacks a proper lifecycle management, potentially causing resource leaks.

Comment on lines +147 to +149
private final ExecutorService stateNotificationExecutor =
Executors.newCachedThreadPool(
GcpThreadFactory.newThreadFactory("gcp-mc-state-notifications-%d"));
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using Executors.newCachedThreadPool() can lead to thread exhaustion if tasks are submitted faster than they can be processed, as it creates an unbounded number of threads. Consider using a ThreadPoolExecutor with a bounded queue and a fixed or limited number of threads to prevent potential resource exhaustion.

References
  1. For safety, use a bounded thread pool (e.g., ThreadPoolExecutor with a defined maximum size) instead of an unbounded one (e.g., Executors.newCachedThreadPool()), even if the current logic seems to limit concurrent tasks.

Comment on lines +186 to +187
private static final ScheduledThreadPoolExecutor SHARED_BACKGROUND_SERVICE =
createSharedBackgroundService();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The SHARED_BACKGROUND_SERVICE is a static ScheduledThreadPoolExecutor that is never shut down. This can lead to a resource leak, especially in environments where the classloader might be reused or multiple instances of GcpManagedChannel are created and destroyed. Consider managing the lifecycle of this executor or using a shared, managed executor service.

@rahul2393 rahul2393 requested a review from blakeli0 May 13, 2026 15:27
@rahul2393 rahul2393 force-pushed the migrate-grpc-gcp-java branch from 5e64f56 to 1409dc3 Compare May 13, 2026 15:58
Comment thread java-spanner/grpc-gcp/pom.xml Outdated
<dependency>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-shared-dependencies</artifactId>
<version>${google-cloud-shared-dependencies.version}</version>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would cause circular dependency issues that google-cloud-shared-dependencies manages grpc-gcp version and grpc-gcp also imports google-cloud-shared-dependencies.
Maven build does not error out because it does not validate declared versions in dependencyManagement sections. But it will cause issues in releasing and confusion in dependency management.

I think we have two options:

  1. Treat grpc-gcp a top-level base library like auth. It manages its own dependencies (for now). Its version is managed by first-party-dependencies. It is imported through first-party-dependencies by downstream libraries such as Spanner.
  2. Treat is as a sub module of Spanner and remove it from first-party-dependencies. This is a cleaner solution but it would introduce breaking changes to customers. Now my question is: Is there any grpc-gcp classes exposed on the surface and used by customers directly? If not, there are probably minimum risks.

@rahul2393 rahul2393 requested a review from blakeli0 May 14, 2026 10:59
@blakeli0
Copy link
Copy Markdown
Contributor

Can you update CODEOWNERS so that grpc-gcp is owned by the Spanner team?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this file used? Are the gen code of the this proto file generated during compilation phase and shipped with the jar?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. grpc_gcp.proto defines ApiConfig, MethodConfig, AffinityConfig, and ChannelPoolConfig. Those generated classes are used directly by the main code. The protobuf-maven-plugin runs during compile and it includes in the shipped jar.

Comment thread java-grpc-gcp/pom.xml Outdated
<parent>
<groupId>com.google.cloud</groupId>
<artifactId>google-cloud-shared-config</artifactId>
<!-- Do not depend on the version in this monorepo. It causes publication order problems. -->
Copy link
Copy Markdown
Contributor

@blakeli0 blakeli0 May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an issue for auth but not an issue for grpc-grpc. Because the groupId of grpc-gcp is also com.google.cloud

Comment thread java-grpc-gcp/pom.xml
<junit.version>4.13.2</junit.version>
<opencensus.version>0.31.1</opencensus.version>
<opentelemetry.version>1.57.0</opentelemetry.version>
<spanner.version>6.118.0-SNAPSHOT</spanner.version><!-- {x-version-update:google-cloud-spanner:current} -->
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminder: the Spanner test should be moved to Spanner module right after this PR is merged.

Comment thread java-grpc-gcp/README.md
@@ -0,0 +1,116 @@
# gRPC-GCP for Java

grpc-gcp provides gRPC support for Google Cloud Clients.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a blurb that this module is only used by Spanner?

Comment thread pom.xml
<module>java-gkehub</module>
<module>java-gkerecommender</module>
<module>java-grafeas</module>
<module>java-grpc-gcp</module>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this module name can stay as grpc-gcp-java. All other java-* are a client library but this is more like an implementation details of the client libraries.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can rename it to grpc-gcp-java if preferred, but we would also need to update the root POM generator/metadata flow so root-pom CI keeps it. Otherwise, the generated root POM will drop the module, root-pom CI regenerates pom.xml, and removes non-java-* modules.

Copy link
Copy Markdown
Contributor Author

@rahul2393 rahul2393 May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested grpc-gcp-java against the current root POM generator image, and it has been dropped from the generated pom.xml. So using that path requires a generator change/release, not just this PR.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be fixed in #13211 now. I would prefer it to stay as grpc-gcp-java, similar to google-auth-library-java

@rahul2393 rahul2393 requested a review from blakeli0 May 15, 2026 02:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants