1

Anyone have any idea why multiple calls to menu_rebuild could be made after the site comes up after a successful drush database update? Before I jump down the rabbit hole?

UPDATE:

To clarify I am using Pressflow.

Specifically when we run an update, multiple menu_router rebuilds are called resulting in duplicate key errors and max connection timeouts. The former issue occurs even with smaller updates.

UPDATE: to mitigate against this, is there a non-hack way to increase the lock timeout used by menu_rebuild? It calls that function with no parameters which defaults to 30s and we'd like to increase that.

buddhamagnet
  • 230
  • 2
  • 11

2 Answers2

0

Drupal 6, right?

From what I have read there are some concurrency issues in the menu rebuild code that can cause it to get executed multiple times if multiple users hit the site right after you finish flushing the caches. I have seen this on our Drupal instance...

For example, if I hit "flush all caches" and it takes a few seconds, then I open a second browser and also browse to our site, open a third, etc... depending on how long this takes and the sequence it can trigger multiple menu rebuilds.

After the flush all appears to be fine after the first error.

Here's a couple of long posts I haven't fully read through that explain some of the concurrency issues:

http://drupal.org/node/246653

http://drupal.org/node/251792

hross
  • 3,633
  • 2
  • 27
  • 31
  • Many thanks hross. No, Pressflow. Menu_rebuild is using lock_acquire using the semaphore table but 9 menu_rebuilds are still happening in parallel causing max connection timeouts. This seems to happen most often during long-running updates which suggests the locks are being broken after lock expiration but apparently this has also happened after the end of a successful short update. – buddhamagnet Jun 03 '11 at 07:51
0

We had a similar issue due to a weird condition caused by having admin_menu 1.6, clearing the cache via drush and then loading a page.

If you happen to be using admin_menu 1.6 (and possibly older), I'd recommend disabling it to see if it fixes the problem. Version 1.6 of admin_menu attempts to rebuild the menu in hook_footer, but it does so without using D6's locking functions. So if you have a large menu and the rebuild takes a while, then each hit from an admin user will trigger a new menu regeneration overlapping with the previous one, causing lots of errors.

Just to note, when you clear the cache via the Drupal UI this problem doesn't come up. It is only when you clear the cache via drush, which I believe would happen when you do a db update.

If disabling it fixes the issue, you should consider upgrading to the 3.x version of admin_menu.

As for trying to change the timeout, that won't have any effect. Timeout only effects someone waiting for a rebuild to complete, but it won't start a new rebuild after that 30 seconds either way, it will just let that person continue with however much of the menu is currently rebuilt.

loganfsmyth
  • 156,129
  • 30
  • 331
  • 251
  • Thanks Logan, yep I grepped the codebase and noted admin_menu as a potential offender but the module is disabled. Back to the drawing board and down the rabbit hole! – buddhamagnet Jun 07 '11 at 14:12
  • Oh well, worth a shot! It's got to be something like that that triggers it's own rebuild of the menu, working around the standard locking functions. – loganfsmyth Jun 10 '11 at 01:45