drush データベースの更新が成功した後、サイトが起動した後に menu_rebuild への複数の呼び出しが行われる理由を知っている人はいますか? うさぎの穴に飛び込む前に？
アップデート：
明確にするために、私はPressflowを使用しています。
具体的には、更新を実行すると、複数の menu_router 再構築が呼び出され、重複キー エラーと最大接続タイムアウトが発生します。前者の問題は、小規模な更新でも発生します。
更新: これを軽減するために、menu_rebuild で使用されるロック タイムアウトを増やすハック以外の方法はありますか? パラメータなしでその関数を呼び出しますが、デフォルトは 30 秒であり、それを増やしたいと考えています。
Drupal 6、そうですか？
私が読んだところによると、メニュー再構築コードには、キャッシュのフラッシュが終了した直後に複数のユーザーがサイトにアクセスした場合に複数回実行される可能性のある同時実行の問題がいくつかあります。Drupalインスタンスでこれを見たことがあります...
たとえば、[すべてのキャッシュをフラッシュ]をクリックして数秒かかる場合は、2番目のブラウザを開き、サイトを参照したり、3番目のブラウザを開いたりします。これにかかる時間と順序によって異なります。複数のメニューの再構築をトリガーします。
フラッシュ後、最初のエラーの後、すべてが正常に表示されます。
並行性の問題のいくつかを説明する、私が完全には読んでいないいくつかの長い投稿があります：
admin_menu 1.6 を使用し、drush を介してキャッシュをクリアしてからページをロードすることによって引き起こされる奇妙な状態により、同様の問題が発生しました。
たまたま admin_menu 1.6 (およびそれより古いバージョン) を使用している場合は、それを無効にして問題が解決するかどうかを確認することをお勧めします。admin_menu のバージョン 1.6 は、hook_footer でメニューを再構築しようとしますが、D6 のロック機能を使用せずに再構築します。そのため、大きなメニューがあり、再構築に時間がかかる場合、管理者ユーザーからのヒットごとに新しいメニューの再生成がトリガーされ、前のメニューと重複して多くのエラーが発生します。
Drupal UI を介してキャッシュをクリアすると、この問題は発生しません。これは、drush を介してキャッシュをクリアした場合にのみ発生します。これは、db の更新を行うときに発生すると思われます。
無効にすることで問題が解決する場合は、admin_menu の 3.x バージョンへのアップグレードを検討してください。
タイムアウトを変更しようとしても、何の効果もありません。タイムアウトは、再構築が完了するのを待っている人にのみ影響しますが、その 30 秒後に新しい再構築を開始することはなく、現在再構築されているメニューの多くをその人が続行できるようにするだけです。