[GitHub] [incubator-pegasus] cauchy1988 removed a comment on issue #840: add 'feature flags' rcp interface for version compatability between server and client

[GitBox <gi...@apache.org>]

cauchy1988 removed a comment on issue #840:
URL: https://github.com/apache/incubator-pegasus/issues/840#issuecomment-1018390994


   > > ## 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
   > 
   > **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
   
   **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........


-- 
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: dev-unsubscribe@pegasus.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pegasus.apache.org
For additional commands, e-mail: dev-help@pegasus.apache.org