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

* Your Email Address
* Spam protection	Enter the letters below: .. .. .___.___. \|\| \|\| [__ \| \__\|\|__\|\|___[___ \|
Comment	>>> If Kronolith for some >>> reason sends 15 listEvents requests in a row, it is a reasonable >>> assumption that the 15th is the least important request. It should >>> not, by virtue of random luck, suddenly jump to 2nd in the queue. >> >> For the sake of completeness, the earlier requests are the requests >> that are (supposed) to take the least amount of time to complete. >> I.e., internal calendars. The later requests are those that may take >> a longer time, such as remote calendars. > > I wonder if one compromise option is to lump all "internal" calendars > into a single request, and all "other" calendars into a second > request. > >>> ... especially since I am not convinced that the use-case here is >>> what needs enhancement, not the session storage. >> >> Your earlier comment about it working that way "because that's the >> way the javascript code was written." isn't correct. It was written >> that way because we don't want the user waiting for EVERY SINGLE >> calendar to be loaded into memory before we send anything back to the >> client and update the UI. > > OK. I wasn't sure how listEvents were being sent. I agree with this > from a UI perspective. Aside: it would be really nice for some sort > of PHP solution to allow for bi-directional communication regarding > this kind of polling. see http://wiki.horde.org/Project/H6TODO > and/or reactphp Obviously this isn't useful now, but something to > look at in the future. > >> This would create an unnecessary wait time >> for users that have, e.g., any slowly responding remote calendars. > > Unfortunately, the problem as it currently stands is that you can > possibly/easily create a pretty bad DoS situation for the current > user. > > Say a user has 20 remote calendars defined. (It sounds like Arjen > has ~15, so this is not an excessive number). Worst case scenario: > those 20 remote calendars are reachable ... meaning they won't reject > network connection attempts ... but the actual services on those > servers don't return anything. The connections just sit in wait > states. > > 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. > >> IMO, it doesn't make any sense to force this extra wait time on the >> user because one of the (not even recommended) session handlers >> doesn't work satisfactorily. > > My example is session-handler agnostic. > > Seems to me a better solution, from a performance perspective, is to > manually close the session while the remote calendars are being > fetched. (Even better, if the session data is unchanged in the > listEvents call, you don't even need to reopen the session after it > is completed.) This is what we do in IMP when: > * listing Mailboxes > * building mailbox list > * building message display data > to prevent these kind of DoS issues.
Attachment
Watch this ticket

Saved Queries