python manager与basemanager_使用Python多处理管理器(BaseManager/SyncManager)与远程计算机共享队列时出现管道中断...

在上个月,当我们试图使用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启动新连接?

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值