use mutex to lock protection around client conn during reconnect#2484
use mutex to lock protection around client conn during reconnect#2484kadisi wants to merge 1 commit intocontainerd:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2484 +/- ##
=======================================
Coverage 44.76% 44.76%
=======================================
Files 93 93
Lines 9555 9555
=======================================
Hits 4277 4277
Misses 4585 4585
Partials 693 693
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
please remove this and place it in your global gitignore.
|
I am OK adding the lock for now (yes I know I advocated for it). I think we should completely ditch |
|
Reconnect was to handle cases where containerd has restarted and cached client objects are pointing to a bad connection. |
gRPC already handles this but not when |
|
Steak sauce! |
Signed-off-by: kadisi <[email protected]>
|
@dmcgowan @crosbymichael so , is this pr is ok ? or i still need extra work? |
It's ok, I just didn't want everyone to be surprised if they see a PR removing all the locks later :) |
|
Sorry to just notice this now, but this is the same exact PR as #2465 which hasn't been merged only because the submitter didn't initially have a DCO signoff, and now needs a rebase. Usually, the first PR opened to fix an issue is the one that should get priority unless the original submitter (@fraenkel) isn't interested in doing the rebase. |
|
Just noticed the duplication with #2465 too. |
|
i am very sorry about that , shoud i close this pr ? |
7 participants
Signed-off-by: kadisi [email protected]
What this PR does / why we need it:
use mutex to lock client connection.
Special notes for your reviewer:
Fixes #2335
Release note: