Anonymous | Login | Signup for a new account | 12-17-2024 08:34 PST |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0000176 | [Resin] | minor | always | 05-16-05 00:00 | 11-30-05 14:44 | ||||
Reporter | ferg | View Status | public | ||||||
Assigned To | |||||||||
Priority | urgent | Resolution | fixed | ||||||
Status | closed | Product Version | 3.0.13 | ||||||
Summary | 0000176: session timeout must match the persistent store timeout | ||||||||
Description |
RSN-176 (rep by Forrest Girouard) While it appears that sessions are invalidated on timeout they are immediately resurrected somehow (I suppose because they've been persisted) Yes. That's what's happening. upon the next request from the client. Is this a bug or a feature? It was a feature (the persistent timeout was longer than the memory session timeout), but is now considered a bug since there should only be a single timeout. So the cause of the bug is a delay due to the persistent timeout sweep being very slow (3h default), while the memory timeout being relatively quick (30min). That's now considered a bug, but the fix will wait until 3.0.14, not 3.0.13. |
||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
05-16-05 00:00 | ferg | New Issue | |
11-30-05 00:00 | administrator | Fixed in Version | => 3.0.14 |
11-30-05 14:44 | ferg | Status | resolved => closed |
Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed. 26 unique queries executed. |