[Tickets #13231] Re: Hashtable session handler doesn't unlock on session close

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13231
------------------------------------------------------------------------------
  Ticket             | 13231
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Hashtable session handler doesn't unlock on session
                     | close
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-05-29 13:59) wrote:

>> If you send 20 requests, and each request has to time out, this is 20
>> request * 30 seconds (the default) = 10 minutes.  Some of those PHP
>> requests may timeout... but from my experience you can't count on
>> this - and this can also be disabled locally in php.ini.  So you've
>> essentially locked the user out of accessing Horde for 10 minutes.
>
> I agree, but isn't this the same, even if the requests were lumped  
> together? We still need to wait for the responses from all the  
> calendars before we send the response.

Yes, if php max execution time is not set.

But obviously no if it is set and enforced.  You cut the time down  
from 10 minutes -> 30 seconds in that example.

> I may be wrong, and Jan can correct me if I am, but I believe we  
> already DO close the session while fetching the calendars...or maybe  
> I misunderstand what you mean.

Well... kind of.  First, it is not being done properly, via  
Horde_Session (i will fix this), so $session is invalid after the  
session is reopened.

Second... I question whether we even need to have a writable session  
at all for this call.  Seems like we could add listEvents to the  
$_readOnly list.  The only places we are setting values in $session in  
Kronolith seem to be:

attendees.php
lib/Ajax/Application/Handler.php (in saveCalendar, so irrelevant for  
listEvents)
lib/View/EditEvent.php
lib/CalendarsManager.php
new.php

Other than Handler.php, the rest is UI related code and doesn't seem  
pertinent to listEvents activity.