| Anonymous | Login | Signup for a new account | 04-23-2024 06:37 PDT |
| Main | My View | View Issues | Change Log | Docs |
| Viewing Issue Advanced Details [ Jump to Notes ] | [ View Simple ] [ 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 | Platform | |||||
| Status | closed | OS | |||||||
| Projection | none | OS Version | |||||||
| ETA | none | Fixed in Version | 3.0.14 | Product Version | 3.0.13 | ||||
| Product Build | 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. |
||||||||
| Steps To Reproduce | |||||||||
| Additional Information | |||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0000200) ferg 05-16-05 00:00 |
server/016u |
|
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. |  |
