[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               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


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

>> 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.