How to detect protocol mismatch when using Apache Thrift?
I am running a couple of client and server programs communicating with Apache Thrift on my Mac. In our production system, we might find ourselves in a situation where the client uses TJSONProtocol
and the server uses TBinaryProtocol
for serialization and deserialization.
I know it's awful. But I'm not sure how to detect this earlier. I tried the sample program with different protocols. I was expecting to get an exception, but the client got stuck in the RPC call and never returned.
Server code with TBinaryProtocol
:
shared_ptr<SomethingHandler> handler(new SomethingHandler());
shared_ptr<TProcessor> processor(new SomethingProcessor(handler));
shared_ptr<TServerTransport> serverTransport(new TServerSocket(port));
shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory());
shared_ptr<TProtocolFactory> protocolFactory(new TBinaryProtocolFactory());
TSimpleServer server(processor, serverTransport, transportFactory, protocolFactory);
server.serve();
Client code using TJSONProtocol
:
boost::shared_ptr < TSocket > socket(new TSocket(argv[1], 9090));
boost::shared_ptr < TTransport > transport(new TBufferedTransport(socket));
boost::shared_ptr < TProtocol > protocol(new TJSONProtocol(transport));
transport->open();
std::cout<<"Transport open success"<<std::endl;
SomethingClient client(protocol);
std::cout<<"Create client success"<<std::endl;
try{
std::cout<<"About to ping"<<std::endl;
client.ping(argv[2]);
std::cout<<"Ping success"<<std::endl;
}catch(TException e){
std::cout<<"Exception occurred:"<<e.what()<<std::endl;
}
transport->close();
In this example, I never get Ping success
to print. Is there a way to detect this incompatibility without getting stuck?
source to share
I'm afraid you can't. By definition, you must install the same protocol / transport stack 1) at both ends; everything else is simply not valid.
If you need different protocols / transport stacks, you need to configure the appropriate number of different endpoints.
There is no protection or detection other than the usual mechanisms at higher levels of the stack. The reason you are stuck is most likely misinterpreting the data, so the server is probably just waiting for more bytes of requests that you are not sending.
1) There are some exceptions to this rule, but they are irrelevant here.
source to share