You need to update IMP to 4.2-alpha, or not use IMP authentication.

This broke iCalendar support (in version 2.1.5): Sunbird can no longer 
read my calendar and it is also impossible to read the ics file using 
a web browser.



When I remove the line "$session_control = 'none';" from ics.php, it 
works again.

This was a really obscure problem with IMP application auth (having to 
do with Secret::read()). It's fixed now, so I've put back the 
$session_control = 'none' code.

I'm not sure, but with disabling session authentication with calendar 
clients don't stick. It's sufficient to have a read-only but that 
would still lock the session if I'm not mistaken.

A simple answer is that we use the session to cache results of remote 
calendar lookups. A more complicated answer is that we do a _lot_ of 
caching in the session, and it'd take a lot of careful work to make 
sure that we do everything we need to the session, including all 
possible preferences changes, then close the session (or write close, 
anyway), and only then list events.



Jan, do you remember what about remote calendars needs a session in 
ics.php? If we can't fix that, either we can do that work to close the 
session before listing events, we can try to recognize shares on the 
same server and translate them internally. If I understand the problem 
right we can't really pin this on table-level locking since at best a 
user would still be able to lock their own session up, right?

I completely agree that using a remote share on the same horde server 
is silly.  However, since a user can effectively hang the Horde server 
if they do this, should there be some sort of warning or protection?



Actually, why is the page fetching the remote calendar still holding a 
lock on the session table at this point anyways?

Given the requirement for both disabling row-level locking (bad idea) 
and using remote shares on the same horde server (why?), while this is 
a bug, I'm not sure it's worth figuring out a way around it...

I had to revert it unfortunately because it *did* break remote calendars.

Yep, that fixes it for me.



Thanks!

Can you please try if the following patches fix the problem, and don't 
break remote calendars:

http://lists.horde.org/archives/cvs/Week-of-Mon-20070312/065963.html

When row-level locking is disabled (using MyISAM tables, for example) 
in Horde, it is possible to create a race/deadlock condition on the 
session table when viewing a remote calendar that is hosted on your 
server.



To reproduce this problem, add your own calendar (such as 
https://example.com/kronolith/ics.php?c=bob@example.com) as a remote 
calendar in Kronolith's Options.  Click on "Today" and then select the 
remote calendar from the "Select calendars to display:" drop-down list.



At this point, two separate Apache processes will be holding a lock on 
the session table, and any new pages requiring access to the session 
table will hang.