什么是解决Plone死锁问题的现代方法？

Question

我目前有一个Plone 4.3.8网站，编辑portlet导致死锁。

我正在尝试找到解决此问题的工具，但大多数死锁工具无法正常工作。我从那些至少跑步的人那里得不到好的信息（IMO）。

我试过了：

• z3c.deadlockdebugger =＆gt;无法进入堆栈跟踪
• ZopeHealthWatcher =＆gt;无法在命令行（或网页）上看到结果
• Products.LongRequestLogger =＆gt;也许是目前为止最好的，给我一些日志输出 - 但它的堆栈跟踪专注于Diazo代码，但是当Diazo不在范围内（运行127.0.0.1）时问题仍然存在
• gdb attach - 刚刚使用C代码
• winpdb =＆gt;它不能以与gdb相同的方式连接到正在运行的进程（仅限于以winpdb为附加意图启动的进程）
• Products.signalstack（OR Products.signalstacklogger）=＆gt; USR1信号只是关闭了一个zope进程！

注意：z3c.deadlockdebugger（以及依赖它的东西）需要签出source code以删除线程框架依赖项。

我的情况似乎与产品升级有关 - 可能是plone.app.contenttypes或plone.app.multilingual中的一个或两个，空站点没有此问题，但我显然需要我的站点数据！

我该怎么做才能取得进展？

编辑：

我相信Maurits的答案是最正确的，但在我的情况下并不起作用。我最终做的是使用pdb来追踪代码挂起的位置（在plone.app.debugtoolbar中发生）

Answer 1

你说在使用Products.signalstack时使用USR1信号会关闭Zope。但是不需要特殊的包，所以我想知道添加signalstack是否会产生关闭Zope的副作用。

至少对我而言，几周前，这在Plone 4.3.something网站上运行良好：

kill -USR1 $(cat var/zeoclient.pid)

Answer 2

虽然@maurits的答案是对的（也是最简单的答案），但有时我会看到kill命令导致的追溯问题：有时会在事件日志中找到，有时候会在shell上找到。

我更喜欢将buildout与haufe.requestmonitoring集成，同时配置monitor long running requests feature。 您将在事件日志中看到死锁回溯，并激活用于监控Plone低性能的工具。