This issue only concerns mod_perl or speedycgi sites:
The Sessions-dont-flush-on-exit problem discussed on
TWiki:Plugins.SessionPluginDev
still exists in Dakar-in-spe. That causes
- hundreds of thousands of cgisession_* files in /tmp
- (too often) zero-filesize session files, causing the clients browser to endlessly load topics
OK
bizzare, i turn on speedycgi, and promptly get no cgi_sess files in /tmp at all
and with mod_perl, it is expireing properly.
are you using the beta2, svn or what, and which apache etc?
-- SD
- svn #7000
- apache 1.3.3.-6sarge
- speedy 2.22
With $TWiki::cfg{UseClientSessions} = 0; I can avoid the problem; but that is just a workaround.
--
OK
The problem (I think) is due to the mix of CGI::Session and mod_perl.
When a guest user performs a transaction, a CGI::Session is used to establish whether they have an existing session or not. When CGI::Session::new is called, it always creates a session if an existing session can't be made. However a session for the guest user is not useful, so to avoid the cost of writing a file, we don't flushthe session. In normal cases, the zero-sized file doesn't get created because the process exits, and the session file is just automatically deleted. With mod_perl, the process remains alive, the file handle still exists, so you see zero sized "files" that are actually just sessions that never got flushed.
There was a hack in
SessionPlugin to delete these sessions, but it caused the Apache server to fail when CGI::Session::delete tried to delete a session file that didn't exist. With Dakar I tried expiring the session immediately and always flushing it anyway, but I had the impression that did bad things to performance. The obvious solution is always to manage guest sessions more carefully, and flush them. There are some comments in the code (from
SessionPlugin) that support this argument.
CC
I don't know, if it is relevant, but in my test environment only (apache) authenticated users are allowed. As far as I can see, there are no guest user transactions. --
OK
fixed in svn 7192.
MD