在上个月，当我们尝试使用 Python 2.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 "<string>", 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 的管理器托管)。
这个问题的特殊之处在于，如果我们在一台机器上连接到这个共享队列(我们称这台机器为 机器 A)，即使是来自许多并发进程，我们似乎也永远不会遇到问题。只有当我们从其他机器(我们称这些机器为 机器 B 和 C)连接到队列(同样，使用一个扩展多处理 SyncManager 的类并且当前不添加额外功能)并运行大量在我们遇到问题的同时将项目放入队列和从队列中取出。
就好像 python 的多处理包处理本地连接(即使它们仍然使用相同的 manager.connect() 连接方法)以一种在 machine A 上工作的方式但是当远程连接是从至少一台 机器 B 或 C 同时生成，我们得到一个 Broken pipe 错误。
在我的团队所做的所有阅读中，我们认为问题与锁定有关。我们认为也许我们不应该使用 Queue.Queue，而应该使用 multiprocessing.Queue，但是我们切换了，问题仍然存在(我们还注意到 SyncManager 自己的共享 Queue 是一个Queue.Queue 的实例)。
我们正在努力解决如何调试这个问题，因为它很难重现，但确实经常发生(如果我们从队列中插入和 .get()ing 大量项目，每天会发生很多次)。
我们创建的方法 get_from_queue 尝试以随机休眠间隔重试从队列中获取项目约 10 次，但似乎如果它失败一次，它将失败所有十次(这导致我相信 .register() 和 .connect()ing 到管理器可能不会给服务器提供另一个套接字连接，但我无法通过阅读文档或查看 Python 内部源代码来确认这一点) .
任何人都可以提供任何有关我们可能查看的位置或我们可能如何跟踪实际发生的事情的见解吗？
我们如何使用 multiprocessing.BaseManager 或 multiprocessing.SyncManager 在管道损坏的情况下启动新连接？
我们如何首先防止管道破裂？
最佳答案
仅供引用 如果其他人遇到同样的错误，在广泛咨询 Python 核心开发团队的 Ask Solem 和 Jesse Noller 之后，看起来这实际上是当前 python 2.6.x(可能是 2.7+，也可能是3.x).他们正在寻找可能的解决方案，并且可能会在未来的 Python 版本中包含修复程序。
关于python - 使用 Python 多处理管理器 (BaseManager/SyncManager) 与远程机器共享队列时管道损坏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3649458/