Repository navigation
Conversation
5add899 to
bbeee76
Compare
bbeee76 to
a79bd30
Compare
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
5 open issues
static_cast<SubChannel*>(ptr->user())->chandereferencesptr->user()without validating it is… · New Same issue as inCheckHealth():ptr->user()is dereferenced without null/type validation. If… · New Same issue as inCheckHealth():ptr->user()is dereferenced without null/type validation. If… · NewASSERT_TRUE(blocking->started())can cause the test process to hang: if this assertion fails,… · New TheAddChannel()completion wait is capped at ~100ms, which is prone to CI flakiness under… · New
What changed in this PR
This PR reduces lock contention in SelectiveChannel by snapshotting sub-channel SocketIds under ChannelBalancer::_mutex, then releasing the lock before running potentially slow CheckHealth() / verbose Describe() on each sub-channel. It also adds a regression test to ensure verbose Describe() doesn’t block AddChannel().
Changes:
- Snapshot sub-channel
SocketIds while holdingChannelBalancer::_mutex, then resolve/access sockets after unlocking. - Update
CheckHealth()and verboseDescribe()to useSocket::AddressFailedAsWell()+SocketUniquePtrfor safe access. - Add a unit test ensuring verbose
Describe()doesn’t blockAddChannel().
| File | Description |
|---|---|
| test/brpc_channel_unittest.cpp | Adds a regression test with a blocking sub-channel Describe() to verify AddChannel() is not blocked by verbose Describe(). |
| src/brpc/selective_channel.cpp | Reworks CheckHealth() / verbose Describe() to avoid holding _mutex while invoking sub-channel operations by using snapshot-based iteration. |
Review effort: Lite
ac390a3 to
edc0e2b
Compare
edc0e2b to
77e5818
Compare
c6c1a56 to
461fdc9
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Concurrent removal can leave unlocked readers accessing deleted, externally owned sub-channels.
2 open issues
4 resolved since last review
ASSERT_TRUE(blocking->started())can cause the test process to hang: if this assertion fails,… Same issue as inCheckHealth():ptr->user()is dereferenced without null/type validation. If… Same issue as inCheckHealth():ptr->user()is dereferenced without null/type validation. If…static_cast<SubChannel*>(ptr->user())->chandereferencesptr->user()without validating it is…
Review effort: Balanced


What problem does this PR solve?
Issue Number: resolve
Problem Summary:
SelectiveChannel::CheckHealth()and verboseDescribe()invoke sub-channelmethods while holding the channel map mutex. Slow sub-channel operations can
therefore delay concurrent add and removal operations.
What is changed and the side effects?
Changed:
OWNS_CHANNELregistrations, resolvingand accessing them after releasing the channel map mutex.
DOESNT_OWN_CHANNELregistrations so that removalcannot return and allow the caller to destroy an externally owned channel
while it is being accessed.
Side effects:
CheckHealth()and verboseDescribe()may observe a weakly consistent viewof owning registrations during concurrent add or removal operations.
Non-owning registrations retain the previous synchronization behavior to
preserve their lifetime contract.
Performance effects:
removal operations when health checks or verbose descriptions of owning
sub-channels are slow.
Breaking backward compatibility:
Check List: