AnDiXL commented on code in PR #3559:
URL: https://github.com/apache/brpc/pull/3559#discussion_r4471029971
##########
src/brpc/options.proto:
##########
@@ -67,6 +67,7 @@ enum ProtocolType {
PROTOCOL_H2 = 27;
PROTOCOL_COUCHBASE = 28;
PROTOCOL_MYSQL = 29; // Client side only
+ PROTOCOL_FLATBUFFERS_RPC = 30;
Review Comment:
Thanks, you're right: the registration position in `global.cpp` had no
effect, and fb_rpc was probed at 30. I kept the numbers and
`_handlers[ProtocolType]`, and `InputMessenger` now keeps a separate probe
order. It is protocol-number order except that fb_rpc is moved right after
baidu_std (a one-entry table in `input_messenger.cpp`). The order is computed
once when the handler array is allocated and never changes, so the lock-free
read in `CutInputMessage()` stays as it was. Messengers using
`AddNonProtocolHandler()` keep insertion order. Nothing that relies on handler
indices changes: the preferred index, the baidu_std/streaming_rpc fallback and
the NSHEAD check in `/connections`. New test
`FlatBuffersProbeOrderTest.ProbedRightAfterBaiduStd` registers a reject-all
protocol at ID 20 and checks that an FRPC connection never reaches it. It fails
when probing goes back to number order.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
