[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 Rubinsky <mrubinsk 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 Rubinsky <mrubinsk at horde.org> (2014-05-29 18:38) wrote:


> I wonder if one compromise option is to lump all "internal"  
> calendars into a single request, and all "other" calendars into a  
> second request.

I agree it's an option. I think I even may have suggested this in the  
other ticket.
> 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.

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. The user would, in this case,  
not see ANY calendars in their interface for 10 minutes in your above  
example, no?

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

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.