| Summary | session oversized for memcache |
| Queue | Horde Framework Packages |
| Queue Version | HEAD |
| Type | Bug |
| State | Resolved |
| Priority | 2. Medium |
| Owners | slusarz (at) horde (dot) org |
| Requester | adrieder (at) sbox (dot) tugraz (dot) at |
| Created | 08/30/2007 (6491 days ago) |
| Due | 08/31/2007 (6490 days ago) |
| Updated | 09/05/2007 (6485 days ago) |
| Assigned | 08/30/2007 (6491 days ago) |
| Resolved | 09/05/2007 (6485 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Version ⇒ HEAD
Queue ⇒ Horde Framework Packages
State ⇒ Resolved
State ⇒ Assigned
New Attachment: Memcache.php.patch
We always wrote "number of slabs + 1", as the number of used slabs for
oversized items to "horde_memcache_os".
This was no problem for caching items, but it was for sessions because
the "get" method would then return "false" for the last item (slabs +
1) which of coures does not exist. The session handler gets false and
kicks out the logged in user.
Priority ⇒ 2. Medium
Type ⇒ Bug
Summary ⇒ session oversized for memcache
Due ⇒ 08/31/2007
Queue ⇒ IMP
State ⇒ Unconfirmed
related to IMP.
We have a user with over 36,000 messages in his INBOX. If the
sessionhandler is set to memcache, then the user will be logged out
when trying to compose and send a new message after he/she logged in.
It seems that the session gets destroyed somehow because of its size.
When I switch to the mysql sessionhandler the problem is gone. And I
see that the session has a szie of ~2.8Mb. I thought that this shold
not be a problem for the memcache cache driver anymore, at least not
when using it for caching things. Is the storing of sessions handled
differently?