在上个月，当我们试图使用Python2.6.x多处理包在几个不同的(linux)计算机之间共享队列时，我们遇到了一个持久的问题。我也直接向Jesse Noller提出了这个问题，因为我们还没有找到任何解释StackOverflow、Python文档、源代码或其他在线问题的东西。

我们的工程师团队还没有解决这个问题，我们已经向python用户组中的很多人提出了这个问题，但没有效果。我希望有人能给我一些启示，因为我觉得我们做了一些不正确的事情，但离问题太近了，看不出它是什么。

症状如下：Traceback (most recent call last):

File "/var/django_root/dev/com/brightscope/data/processes/daemons/deferredupdates/servers/queue_server.py", line 65, in get_from_queue

return queue, queue.get(block=False)

File "", line 2, in get

File "/usr/local/lib/python2.6/multiprocessing/managers.py", line 725, in _callmethod

conn.send((self._id, methodname, args, kwds))

IOError: [Errno 32] Broken pipe

(我展示了代码在共享队列对象上调用queue.get()的位置，该对象由扩展SyncManger的管理器托管)。

这个问题的特殊之处在于，如果我们在一台机器上连接到这个共享队列(我们称之为machine A)，即使是从许多并发进程，我们似乎也不会遇到问题。只有当我们从其他机器(我们称之为machines B and C)连接到队列(同样，使用扩展了多处理同步管理器并且当前没有添加任何附加功能的类)并在队列内外运行大量项目时，我们才会遇到问题。

这就好像python的多处理包处理本地连接(即使它们仍然使用相同的manager.connect()连接方法)的方式与machine A相同，但是当至少从machines B or C中的一个同时进行远程连接时，我们会得到断管错误。

在我的团队所做的所有阅读中，我们认为问题与锁定有关。我们认为也许不应该使用Queue.Queue，而应该使用multiprocessing.Queue，但是我们进行了切换，问题仍然存在(我们还注意到SyncManager自己的共享队列是Queue.Queue的一个实例)。

我们正在讨论如何调试这个问题，因为它很难重现，但确实相当频繁(如果我们插入和.get()队列中的许多项，每天会发生很多次)。

我们创建的方法get_from_queue尝试用随机睡眠间隔从队列中重试获取该项约10次，但似乎如果失败一次，它将失败10次(这使我相信，到管理器的.register()和.connect()可能没有提供到服务器的另一个套接字连接，但我无法确认这可以通过阅读文档或查看Python内部源代码来实现)。

有谁能提供一些我们可能看到的地方，或者我们如何跟踪实际发生的事情？

如果管道损坏，我们如何使用multiprocessing.BaseManager或multiprocessing.SyncManager启动新连接？

我们怎样才能从一开始就防止管道破裂呢？