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	> >> 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. >
Attachment
Watch this ticket

Saved Queries