我有一个使用upper.io/db包与Mongo数据库服务器（这是gopkg.in/mgo.v2相当简单的包装器）进行通信的应用程序。应用程序的工作方式是它在启动时在主线程中创建一个会话，然后每个需要向mongo服务器发出请求的go例程在会话上调用Clone并执行{{1结果值。据我所知，这是所有标准操作程序。
此设置在我们的开发环境中没有任何错误，我们在MongoLab上使用本地运行的MongoDB 或沙箱实例。最近我们将应用程序升级到我们的暂存环境，我们让应用程序与MongoLab上的MongoDB共享集群实例（最便宜的15 $选项）进行通信。这就是奇怪的事情开始发生的地方。 / first /请求通过（从第一个被调用的go-routine）返回预期的响应，但后续的都返回
defer session.Close这是从我们指向集群的本地开发计算机或登台环境的AWS主机发生的。由于Mongo集群来自Mongolabs，我将假设他们已经在他们的最终正确配置了所有内容。
代码有点无聊TBH：它实际上只是在main函数中打开会话并维护对它的引用，然后有多个具有这种基本结构的goroutine：
read tcp <ip address>:47112: i/o timeout
在测试期间，我甚至限制它一次只运行一件事（即在任何给定时间只有一个goroutine处于活动状态），并且它仍然以相同的方式失败。
以前有人碰到过吗？我是否需要以特定方式配置upper.io/db？也许直接使用mgo？我最终知道这一点:(
答案 0 :(得分：0)
在一个相当漫长而艰苦的过程中，我们最终找到了此问题以及类似问题在程序中的出处。最终成为upper.io/db库的v1版本中的会话泄漏。该错误和修复程序是outlined here，但是此库的v1版本目前已经过时了，以后的版本则没有这个问题。
我怀疑这个答案对游戏中如此晚的任何人（特别是因为我们自己像3年前就这样解决了这个问题）是否有用，但只是想将答案留在此处以保持完整性。