Mihir-Rabari opened a new pull request, #3387: URL: https://github.com/apache/hugegraph/pull/3387
PD's raft rpc server was built with `RaftRpcServerFactory.createRaftRpcServer`, which registers jraft's CLI membership processors on the raft port next to the replication ones. A jraft `CliService` client that can reach a PD raft port can then add, remove or reset peers and learners, or transfer the leadership, skipping the checks PD runs on its own membership paths: the odd peer count check and the `IpAuthHandler` refresh in `RaftEngine#changePeerList`, and the validation in `PDService#updatePdRaft`. I now create the rpc server the same way the factory does internally (`RpcFactoryHelper.rpcFactory().createRpcServer`) and register only the raft replication processors, so membership changes have to go through PD's own entry points. PD's `GetMember` request processor and the raft IP whitelist wiring are untouched. `RaftRpcServerFactory`'s static block is the only place jraft registers the protobuf codecs for raft messages, so `createRaftRpcServer` calls `ProtobufMsgFactory.load()` itself now; without it a multi-node PD cluster could no longer (de)serialize raft messages over bolt. `RaftEngineCliProcessorsTest` drives the real `createRaftRpcServer` on an ephemeral port and asserts that no CLI membership processor is registered while the replication processors and PD's `GetMemberRequest` still are; it runs in `PDCoreSuiteTest`. The issue is about the PD raft port; the server and store raft ports still register jraft's CLI processors and are out of scope here. Fixes #3386 -- 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]
