Connection pooling?

[Blake Smith]

For other RPC clients that use HTTP as the codec, connection pooling is handled at the HTTP Client level. Since go-thrift uses a different codec, how should I tackle connection pooling in a concurrent environment?

A few thoughts:

• The RPC documentation says that an RPC client can be accessed from multiple goroutines (http://golang.org/pkg/net/rpc/#Client). Does this simply imply thread safety, or does it imply pooling should be built in to the codec?
• I've thought about wrapping my calls to access the client in something like this: https://gist.github.com/3504674 - but I wanted to see if there was a lower level place that could handle this for me.

What are your thoughts?

Thanks!

Blake

[Samuel Stauffer]

Sorry for taking so long to get back to you on this.

I'm leaving the connection pooling out of the go-thrift library since it's really using the built in RPC package in Go (which is safe for concurrent use). To add connection pooling it would be best to add a layer around that package. The strategy to choose a connection may get tricky though since it's asynchronous (which is something I should discuss more in the docs.. not all thrift servers support asynchronous requests).