cauchy1988 edited a comment on issue #840: URL: https://github.com/apache/incubator-pegasus/issues/840#issuecomment-1018384900
> ## 1 > > 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... > > Refer to implementation `config update`, you just update after the response of replica is `no support`. rather than boot one scheduled task > > ## 2 > > The server implementation is more complicated and needs to be well tested > > You still need implement same or more code on server side when you use the old design which client negotiation replica server, and the new design just apply the logic to meta and you can re-use `config-sync`, so I think it shouldn't be `more complicated`. > > You list the update case in > > > according to three possible situations > > Actually, you may not consider these different case, the `config-sync` just `run` and store the latest value. > > Just like @acelyc111 say: > > > We can extend 'config_sync' betwen MS and RS to include replica server's 'feature map' > > ## 3 > > so the client can only start a periodically scheduled task > > As above, refer to implementation of `meta config` , you don't need periodically scheduled task. > > ## 4 > > but the business code of BATCH_GET rpc is in the pegaus > > They are two feature, and locate different git-rep is acceptable, it will be improved after they are combined **1** I think it is still inevitable to add a scheduled timer update-process, think about this scenerio: java client fetched an already outdated feature list from leader metaserver, and this feature list doesn't contains 'BATCH_GET' feature, then java client will run in old logic; however, the whole server cluster has been upgraded to new version which support the 'BATCH_GET' feature; the dilemma is that : java client will not get the no support response from the replica because replica also support old-logic-interface, and thus the client will go on running in old logic forever........ **2** meta server should remember the feature list of all the replica server in a 'map like' datastructure, and judge one feature is supported only when all featurelist of every replica server contains this feature; so we should dynamically update this "map-like' datastructure in three possible conditions i decribed -- 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]
