Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(bigtable): DataConnection refreshes channels #9718

Merged
merged 2 commits into from
Aug 25, 2022

Conversation

dbolduc
Copy link
Member

@dbolduc dbolduc commented Aug 23, 2022

Fixes #9712

This is mostly a refactor. Update the channel refresh API to accept a shared_ptr<internal::CompletionQueueImpl> instead of a shared_ptr<CompletionQueue>.

Now, we will not back out of the channel refresh loop too early, because the background threads hold onto the CQ object for the lifetime of the stub.

Add a regression test for this behavior that fails at HEAD.


This change is Reviewable

@product-auto-label product-auto-label bot added the api: bigtable Issues related to the Bigtable API. label Aug 23, 2022
@google-cloud-cpp-bot
Copy link
Collaborator

Google Cloud Build Logs
For commit: a57d756a5f9668c963c430a0f86e57f6e834bc11

ℹ️ NOTE: Kokoro logs are linked from "Details" below.

@codecov
Copy link

codecov bot commented Aug 23, 2022

Codecov Report

Merging #9718 (7af728d) into main (18937be) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #9718   +/-   ##
=======================================
  Coverage   93.89%   93.89%           
=======================================
  Files        1495     1495           
  Lines      139390   139421   +31     
=======================================
+ Hits       130874   130910   +36     
+ Misses       8516     8511    -5     
Impacted Files Coverage Δ
...bigtable/internal/bigtable_channel_refresh_test.cc 100.00% <100.00%> (ø)
...e/cloud/bigtable/internal/bigtable_stub_factory.cc 100.00% <100.00%> (ø)
google/cloud/bigtable/internal/common_client.h 92.75% <100.00%> (ø)
...loud/bigtable/internal/connection_refresh_state.cc 98.66% <100.00%> (+2.83%) ⬆️
...cloud/bigtable/internal/connection_refresh_state.h 100.00% <100.00%> (ø)
...bigtable/internal/connection_refresh_state_test.cc 100.00% <100.00%> (ø)
...bigtable/examples/bigtable_hello_instance_admin.cc 81.00% <0.00%> (-2.00%) ⬇️
google/cloud/storage/parallel_upload.cc 98.26% <0.00%> (-0.35%) ⬇️
...le/cloud/storage/internal/curl_download_request.cc 89.63% <0.00%> (-0.34%) ⬇️
google/cloud/pubsub/samples/samples.cc 90.77% <0.00%> (+0.07%) ⬆️
... and 3 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@google-cloud-cpp-bot
Copy link
Collaborator

Google Cloud Build Logs
For commit: 7af728d396424d32bb0e0eb1ebefd3b019b0d6ab

ℹ️ NOTE: Kokoro logs are linked from "Details" below.

@dbolduc dbolduc marked this pull request as ready for review August 25, 2022 05:33
@dbolduc dbolduc requested a review from a team as a code owner August 25, 2022 05:33
Comment on lines +89 to +90
EXPECT_LE(ns(ms(500)).count(), duration.count());
EXPECT_LE(duration.count(), ns(ms(1000)).count());
Copy link
Contributor

Choose a reason for hiding this comment

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

Does .count() need to be involved? That is, can't we compare the durations directly?

Copy link
Member Author

Choose a reason for hiding this comment

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

We could compare the durations directly. I think the idea was to have (arguably) better error messages. e.g.

Expected: (ns(ms(1000)).count()) <= (duration.count()), actual: 1000000000 vs 852000000

vs.

Expected: (ms(1000)) <= (duration), actual: 8-byte object <E8-03 00-00 00-00 00-00> vs 8-byte object <00-8E AB-25 00-00 00-00>

Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough. Perhaps consider these options:

  1. Leave it as-is.
  2. Wrap each side of duration expectations in absl::FromChrono, so you even get even nicer output, including units.

Either of these (.count() or wrapping) could disappear when durations become streamable in C++20.

Copy link
Member Author

Choose a reason for hiding this comment

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

I left it as is. I suspect I will need to rewrite the test, anyway. When that happens, I doubt I will use .count() again.

Comment on lines +89 to +90
EXPECT_LE(ns(ms(500)).count(), duration.count());
EXPECT_LE(duration.count(), ns(ms(1000)).count());
Copy link
Contributor

Choose a reason for hiding this comment

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

Fair enough. Perhaps consider these options:

  1. Leave it as-is.
  2. Wrap each side of duration expectations in absl::FromChrono, so you even get even nicer output, including units.

Either of these (.count() or wrapping) could disappear when durations become streamable in C++20.

@dbolduc dbolduc merged commit b7f8b23 into googleapis:main Aug 25, 2022
@dbolduc dbolduc deleted the fix-data-connection-channel-refresh branch August 25, 2022 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: bigtable Issues related to the Bigtable API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix bigtable channel refreshing for DataConnection
3 participants