Pool management calls Thrift goroutine to reduce the overhead of creating and destroying goroutine. C calls client.

C := pool.get () defer pool.put (c) The following is the call logic....Copy the code

Phenomenon of the problem

When the Client calls the Server through the Thrift protocol, only HTTP Status returns 413, but there is no other useful information. The body is also empty.

Question why

Then, it is necessary to analyze the root cause of the problem according to the above phenomenon.

  • So what does HttpStatus 413 mean?

HTTP Status 413 (request entity is too large), and header is too large for this problem.

The server could not process the request because the request entity was too large for the server to handle.

If the entity is too large, it should include header and body.

  • Because when Thrift is used as an RPC framework, the header is set (using the following Addheader method). But for goroutine that exists in the pool,p.header.Add(key, value)I know that if I call Addheader it’s going to keep adding to the contents of the header. So the request entity is too large.
// Set the HTTP Header for this specific Thrift Transport // It is important that you first assert the TTransport as a THttpClient type // like so: // httpTrans := trans.(THttpClient) // httpTrans.SetHeader(" user-agent ","Thrift Client 1.0") func (p \*THttpClient) SetHeader(key string, value string) { p.header.Add(key, value) }Copy the code

The solution

After knowing the root cause of the problem, you need to solve the problem. The recommended solutions are as follows:

  • Reimplement your own inheritance (recommended)

  • Modified the SetHeader/Flush method in the Thrfit package to add resetting header logic

  • The Thrift connection is recreated each time

The environment

  • Go: 1.5

  • Linux version 2.6.32-279.el6.x86_64 (GCC version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)

  • OS: CentOS Release 6.3 (Final) 2.6.32-279.el6.x86_64

  • CPU: 12

  • Mem: 8 g

  • Network protocol: Thrift