Thrift RPC FAQs and experiences

Original article: http://blog.rushcj.com/2010/08/21/try-thrift/

Thrift is a great tool and is an open-source Facebook project. It is currently very active in development and managed by Apache, So it uses Apache
Software license, which is very important, because you can safely modify it and use it in your own project.

It is very important to modify thrift. I think thrift should be used seriously, but it is inevitable to have a deep understanding of thrift, and almost all thrift code should be modified. A communication framework cannot help you do everything, nor rush to use it without understanding it.

1. thrift Java Server/client has a more serious bug (https://issues.apache.org/jira/browse/THRIFT-601), random to the thrift sever listening port to send some data, may cause the server outofmemory, take a look at the code, this bug is a bit earthy.

2. The thrift client thread is insecure. Using multiple threads may cause the server and client program to crash. Each client call to a remote method actually involves multiple socket write operations. Therefore, the client used in each thread must be independent, if multiple threads mix the same client (in fact, using the same socket), the transmission byte order may be disordered, making server outofmemory (refer to 1)

3. Avoid using map or set when defining the data structure of thrift. In CPP, the map is mapped to the classes generated by STD: Map (rb tree) and STD: Set, and thrift, which are not overloaded. "<", You need to manually modify the generated class, otherwise, the link cannot pass. More troublesome.

4. If the client needs to cache the socket based on efficiency, it needs to implement its tTransport class again to support the socket cache pool. Of course, this implementation has little to do with thrift, so it is two times of development. But this is usually the case, right?

5. If the client caches the socket based on efficiency, the mode selection on the thrift server is more important. If synchronous tthreadpoolserver is used, it is inevitable that the client caches one socket, and a thread on the server will remain in the server state, waiting for data on the peek socket. This thread cannot be used for other requests. Therefore, it is necessary to promptly clear the client socket and control the size of the socket pool.

6. I heard from my colleagues about the efficient epoll nonblocking mode of CPP thrift server. In fact, it is very convenient for servers with low concurrency requirements to use the epoll in the lt mode. Of course, you have to patch the thrfit server yourself, but it is not troublesome. It is also very convenient to develop. I want to add a serverEpolloneshot.

7. the tthreadpoolserver and tthreadserver under CPP are caused by an interesting problem. If a client maintains a persistent connection, the server instance will be blocked during the analysis (as mentioned earlier, in peek ...).

8. According to valgrind, thrift CPP seems to have some memory problems. Not detailed.

9. Neither Java nor CPP can be used by the server to obtain the IP and port of the client in a valid way. You can write thriftservereventhandler to handle this issue. If you want to obtain the Client IP and port, you can look at this.