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

Search Results: 435 of 574 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: __ .__ . .. .. . / `[__)\|__\|\|__\|\|\/\| \__.[__)\| \|\| \|\| \|
Comment	>>> 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.
Attachment
Watch this ticket

Saved Queries