[horde] Horde 3.1, memcache sessionhandler, sidebar, and flock()

[Chris Stromsoe]

On Wed, 27 Dec 2006, Chris Stromsoe wrote:

> It looks like the memcache session handler added flock() handling to 
> serialize session access in between 3.0 and 3.1.  I'm looking at the 
> locking as one area that could be problematic.
>
> Right now, the code is structured to always obtain an exclusive lock 
> (LOCK_EX).  Is that necessary?  Is there any reason that read() doesn't 
> obtain a shared lock (LOCK_SH) instead?

Never mind that... I see that session handling is read(), modify, write(), 
so it makes sense to lock exclusively in the read call.

I managed to replicate the issue and have tracked the problem to 
/services/portal/sidebar.php, specifically this (lines 238 - 244):

     if ($params['status'] == 'block') {
         $block = &Horde_Block_Collection::getBlock($params['app'], $params['blockname']);
         if (is_a($block, 'PEAR_Error')) {
             Horde::fatal($block, __FILE__, __LINE__);
         }
         $block->buildTree($tree, 0,
                           isset($params['menu_parent']) ? $params['menu_parent'] : null);

     } else {


If I comment out everything inside the if/else, the sidebar loads fine.


The blocks that I'm showing are

  imp-folders
  kronolith-alarms
  kronolith-menu


Modifying the if/else block to be

     if ($params['status'] == 'block') {
         $block = &Horde_Block_Collection::getBlock($params['app'], $params['blockname']);
         if (is_a($block, 'PEAR_Error')) {
             Horde::fatal($block, __FILE__, __LINE__);
         }
         if ($app != 'kronolith-alarms')
             $block->buildTree($tree, 0,
                               isset($params['menu_parent']) ?
                               $params['menu_parent'] : null);
     } else {

also lets the sidebar load.


The sidebar problems are all from users that have probably never used 
kronolith and shouldn't have any events or defined calendar entries.



-Chris