cauchy1988 opened a new issue #840:
URL: https://github.com/apache/incubator-pegasus/issues/840
## Feature Request
**Is your feature request related to a problem? Please describe:**
<!-- A clear and concise description of what the problem is. Ex. I'm always
frustrated when [...] -->
We have optimized an interface implementation of the pegasus java client.
The specific way is to define a new 'task_code' 、bind it to a new read
interface function implemented by the server side and then reimplement the
interface of the java client by calling the new read rpc interface represented
by the new 'task_code'; but this will cause the problem of version matching
between the client side and the server side: the new version client can not
visit old version server because old version server cannot recognize the new
task-code in the request-struct;
Since my company is a "to b" company, we can not upgrade all the deployed
pegasus-server cluster in a comparatively short time;
We don't want to influence the usage of the old client interface either,
so we implement a new java client interface instead with the same functionality
and make it compatible with the new and old version server at the same time.
How to implement the client interface in compatible with the new and old
version server at the same time ?
We have once used an unconsidered method:
we added a 'version' field which represents server code version to the
'configuration_query_by_index_response' structure returned from the
metaserver in the rpc-call represented by the task-code
'RPC_CM_QUERY_PARTITION_CONFIG_BY_INDEX' and then the java client interface
implementation can do the corresponding logic based by this fetched 'version'
field： if ‘version' is higher than some pre-specified number, the remain logic
will execute new optimized code and call the new rpc read interface ;
otherwise, it will be the same with the old logic
This 'unconsidered' method is called 'unconsidered' because it has the
following problems:
(1) 'version' field can only represents metaserver's version, not all the
servers' version in the same pegasus cluster, especially when upgrading is in
progress
(2) it is unreasonble to use an unrelated rpc-call and semantically
unrelated thrift structure 'configuration_query_by_index_response' to fetch
'version' field
(3) It is very inflexible to judge the features supported by the server
simply by comparing the 'code version'
**Describe the feature you'd like:**
<!-- A clear and concise description of what you want to happen. -->
So later we realized that the version matching problem is a general problem,
we thought of a more general method which we call it 'feature flags method',
and the idea is inspired from 'kudu', the method is as following：
1、we can define new features as enums coded in the client side and server
side at the same time
enum rpc_feature_flag {
UNKNOWN = 0,
FEATURE_1 = 1,
}
2、we can also define a new 'task_code', for example
'RPC_CM_FEATURE_NEGOTIATE' and corresponding rpc related definitions：
struct negotiate_request {
}
struct negotiate_response {
1:list<rpc_feature_flag> supported_features;
}
service rrdb {
negotiate_response negotiate(1:negotiate_request request);
}
3、we can then define a new class inherited from 'serverlet' ， implement the
real rpc handler function and register it to 'rpc_engine' in this class when
related 'service_app' start
4、when a java or other language's client establishing connection with each
instance of the server side, it also do the 'negotiate' rpc call to each of
them, then it can 'know' the features each server supported, thus can make
next decisions
The above 'feature flags method' is not particularly detailed, for example
it have not described what the client would do when one of a 'negotiate' rpc
fails
I put it forward here, because I want to hear the opinions of the great gods
here!
**Describe alternatives you've considered:**
<!-- A clear and concise description of any alternative solutions or
features you've considered. -->
**Teachability, Documentation, Adoption, Migration Strategy:**
<!-- If you can, explain some scenarios how users might use this, situations
it would be helpful in. Any API designs, mockups, or diagrams are also helpful.
-->
--
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]
