[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         | arjen+horde at de-korte.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             |
------------------------------------------------------------------------------


arjen+horde at de-korte.org (2014-05-29 19:04) wrote:

> This doesn't help.  As I noted above, 10 requests/second is already  
> fairly heavy usage.  Your solution bumps that up to 20  
> requests/second (you have to assume worst-case scenario).

No, you don't. The requests will follow a Poisson distribution,  
assuming mt_rand is not biased towards certain values. So the with  
increasing number of requests, the average will quickly stabilise  
towards 10 requests/second.

> And there is a general (albeit not mandatory) requirement that  
> requests SHOULD be handled in a FIFO basis. 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.

There is no way (whatever method you use) if these requests are  
handled by separate processes and it is required to get a lock on a  
shared resource. If that is needed, a new request can only be  
initiated when the previous one is know to be active (not waiting to  
get a lock on a resource). Since this is not done, requests can (and  
will be) served in random order. As the cachegrind output I sent you  
also indicates, where the third request that was started is served last.