Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request correctly implements case-insensitive handling for query parameter keys in KeyRecipe by normalizing them to lowercase. The accompanying tests effectively validate this new logic, including edge cases with duplicate keys. I have one minor suggestion to remove a newly added but unused helper method in the test file to improve code clarity.
google-cloud-spanner/src/test/java/com/google/cloud/spanner/spi/v1/KeyRecipeTest.java
Outdated
Show resolved
Hide resolved
ef1e1de to
cd9b0a7
Compare
| tablets = newTablets; | ||
| } | ||
|
|
||
| synchronized ChannelEndpoint fillRoutingHint( |
There was a problem hiding this comment.
Reference: googleapis/google-cloud-go#13877 (comment)
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces two valuable changes. First, it addresses a lock contention issue in KeyRangeCache by refactoring fillRoutingHint to avoid holding a lock during potentially blocking network operations. The implementation correctly uses a pattern similar to double-checked locking to ensure thread safety and handle race conditions. Second, it fixes a bug in KeyRecipe by normalizing query parameter keys to lowercase, enabling case-insensitive lookups. This change is accompanied by thorough unit tests covering various scenarios, including edge cases. Both changes are well-implemented and improve the robustness and performance of the code.
Fixes: b/482811543
KeyRecipe.queryParamsToTargetRange — case-insensitive parameter lookup
The server sends routing recipe identifiers (e.g. "id") that may differ in case from the query parameter names bound by the user (e.g. "Id" or "ID"). Without normalization, the routing key lookup silently missed, causing all requests to fall back to the default endpoint instead of being routed to the optimal server.
Fix: both the recipe identifier and the user's parameter keys are now normalized with toLowerCase(Locale.ROOT) before the HashMap lookup, so case differences no longer cause routing misses.
KeyRangeCache.CachedGroup.fillRoutingHint — avoid holding lock during channel creation
Previously, CachedGroup.fillRoutingHint was a synchronized method, which meant the group lock was held for the entire duration including the call to endpointCache.get(address). That call can block on a network dial when creating a new gRPC channel for the first time, serializing all concurrent routing decisions on the same group.
Fix: the lock is now released before calling endpointCache.get(). The tablet selection (cheap, in-memory) still runs
under the lock. If the endpoint is already cached, it is returned directly without ever releasing the lock (fast path).
If a new channel needs to be dialed, the address is captured, the lock is released, the channel is created, and the lock is re-acquired to update the tablet's cached endpoint atomically — only if the address hasn't changed in the meantime