任何人都知道为什么在成功的 drush 数据库更新后站点出现后可以多次调用 menu_rebuild ?在我跳下兔子洞之前?
更新:
为了澄清我正在使用 Pressflow。
特别是当我们运行更新时,会调用多个 menu_router 重建,从而导致重复键错误和最大连接超时。即使更新较小,也会出现前一个问题。
更新:为了减轻这种情况,是否有一种非黑客方法来增加 menu_rebuild 使用的锁定超时?它调用没有参数的函数,默认为 30 秒,我们希望增加它。
由于 admin_menu 1.6、通过 drush 清除缓存然后加载页面导致的奇怪情况,我们遇到了类似的问题。
如果您碰巧使用的是 admin_menu 1.6(可能更旧),我建议您禁用它以查看是否可以解决问题。1.6 版的 admin_menu 尝试在 hook_footer 中重建菜单,但它没有使用 D6 的锁定功能。因此,如果您有一个大菜单并且重建需要一段时间,那么管理员用户的每次点击都会触发与前一个重叠的新菜单重新生成,从而导致大量错误。
请注意,当您通过 Drupal UI 清除缓存时,不会出现此问题。只有当您通过 drush 清除缓存时,我相信这会在您执行数据库更新时发生。
如果禁用它可以解决问题,您应该考虑升级到 admin_menu 的 3.x 版本。
至于尝试更改超时,那将没有任何效果。超时只会影响等待重建完成的人,但无论哪种方式,它都不会在 30 秒后开始新的重建,它只会让该人继续执行当前重建的大部分菜单。
Drupal 6,对吧?
根据我的阅读,菜单重建代码中存在一些并发问题,如果多个用户在您完成刷新缓存后立即访问该站点,可能会导致它多次执行。我在我们的 Drupal 实例上看到了这个......
例如,如果我点击“刷新所有缓存”并且需要几秒钟,然后我打开第二个浏览器并浏览到我们的网站,打开第三个等等......取决于这需要多长时间和它可以的顺序触发多个菜单重建。
在第一个错误之后,冲洗后一切似乎都很好。
这里有几篇我没有完全通读的长篇文章,解释了一些并发问题: