• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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

  1. hundreds of thousands of cgisession_* files in /tmp
  2. (too often) zero-filesize session files, causing the clients browser to endlessly load topics


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.


Summary Sessions-dont-flush-on-exit problem still exists - from Oliver
ReportedBy OliverKrueger
AppliesTo Engine
Priority Normal
CurrentState Closed

Checkins 7192
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r8 - 2005-10-28 - MichaelDaum
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback