cauchy1988 commented on issue #840: URL: https://github.com/apache/incubator-pegasus/issues/840#issuecomment-1010681932
> If you still want to handle the replica version, you can let meta to sync the replica server in `config_sync` and return the client. > > In short, I think it will be clearer if you only deal with the interaction with meta I thought about how to implement it， and draw a simple picture as below  The main process of implementation is divided into two parts: 1、Interaction between leader meta server and replica server 2、interaction between java client and leader meta server The two parts will be described as follows 1、Interaction between leader meta server and replica server Leader meta server stores the list of feature lists supported by each replica server in its own local memory; at the same time, this list should be modified according to three possible situations: (1) The feature list for some replica server stored in leader meta server is different to feature list received from the config sync request sent by the replica server (2) A replica server was originally not in the local memory records (it was considered to be down before) but is judged alive by the leader meta server, and its corresponding feature list record needs to be added later by corresponding config sync rpc (3) A replica server has been delayed Sending a heartbeat to the leader meta server; so it was judged dead by the leader meta server, and its entire feature list record needs to be deleted from the local memory records Situation(2) and(3) will be triggered by pegasus already realized 'failure_detector' mechanism and thus easy to reuse 2、The interaction between java client and leader meta server The java client may pull outdated feature list data, so we need a timer repeated scheduled function process used to continuously update the local feature list periodically to solve this problem However This implementation still has the following problems: (1)The server implementation is more complicated and needs to be well tested (2)Since the client only pulls the features list from the lead meta server, the client may pull the list of old version, so the client can only start a periodically scheduled task and continuously pull the feature list from the leader meta server to update its local one (3)The codes which meta server interact with replica server and supported feature definition are all in the rdsn, but the business code of BATCH_GET rpc is in the pegaus. although in the future the two code repository will combine into one -- 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]
