[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 11:00) 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).

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.

 From a practical perspective, this is the ONLY place in Horde where  
we are having this issue.  Nowhere else can I think of a place where  
we have more than 1 or maybe 2 session requests queued.  So we should  
not be vastly altering the queue system based on a single use-case ...  
especially since I am not convinced that the use-case here is what  
needs enhancement, not the session storage.