feat(pubsub): implement publish hedging to reduce tail latency - #13735
feat(pubsub): implement publish hedging to reduce tail latency#13735tonyyyycui wants to merge 26 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a hedging mechanism for the Pub/Sub Publisher, adding HedgeSettings for configuration and a thread-safe HedgeTokenBucket to limit hedged requests. The feedback suggests replacing the synchronized methods in HedgeTokenBucket with explicit ReentrantLock to reduce lock contention and improve performance on the critical path.
tonyyyycui
changed the title
tonyyyycui
changed the title
michaelpri10
left a comment
michaelpri10
left a comment
There was a problem hiding this comment.
At a higher level, I think the full implementation should be one PR (instead of the , given any submitted changes become public. It would be unexpected for customers to be able to set HedgingSettings without anything actually happening, so the final PR should have everything needed for the implementation included.
| * | ||
| * @return the hedging delay. | ||
| */ | ||
| public Duration getHedgeDelay() { |
There was a problem hiding this comment.
nit: Does this method need to be public? I think leaving it without an access modifier (i.e., making it package-private) should be sufficient.
There was a problem hiding this comment.
I've removed it for now, but I think it would also make sense if the user could see what they see the hedge delay is set to since it's a configurable field. Leaving this conversation unresolved.
tonyyyycui
changed the title
| final int batchSize = outstandingBatch.outstandingPublishes.size(); | ||
| for (final OutstandingPublish outstanding : outstandingBatch.outstandingPublishes) { | ||
| outstanding.publishResult.addListener( | ||
| new Runnable() { |
There was a problem hiding this comment.
I worried that this approach could have cause additional, unneeded overhead. The cancellation check be done in processQueue instead to avoid needing to create these Runnables, but then we run into an issue of the cancellation not propagating to in-flight hedged requests (i.e., publish at t=0, hedge at t=1000, cancellation at t=1050). This may be okay behavior given that cancellations are best effort. I'll raise this issue with the team.
…and maxtokens, updated tests.
…r for hedgeTokenBucket. Also added HEDGE_TOKEN_SCALE.
…CancellationSharer.java
| } | ||
| this.clock = builder.clock != null ? builder.clock : CurrentMillisClock.getDefaultClock(); | ||
| this.publishContext = GrpcCallContext.createDefault(); | ||
| this.hedgingMetadata = ImmutableMap.of("x-goog-pubsub-hedged", ImmutableList.of("true")); |
There was a problem hiding this comment.
I think we wanted this to be the attempt count, not just true/false. Is it simple to adjust this to something like x-google-pubsub-hedged-count?
d9a8655 to
0b88e33
Compare
4 participants
This PR implements publish hedging in the Java Cloud Pub/Sub Publisher. Specifically, it adds support for scheduling "hedged" publish attempts when a publish call is slow to respond. A token-based method is utilized to rate-limit hedged requests and a coordinator is used to manage/cancel concurrent requests to prevent duplicate publishes.