|
Mantis - Resin
|
|||||
| Viewing Issue Advanced Details | |||||
|
|
|||||
| ID: | Category: | Severity: | Reproducibility: | Date Submitted: | Last Update: |
| 176 | minor | always | 05-16-05 00:00 | 11-30-05 14:44 | |
|
|
|||||
| Reporter: | ferg | Platform: | |||
| Assigned To: | OS: | ||||
| Priority: | urgent | OS Version: | |||
| Status: | closed | Product Version: | 3.0.13 | ||
| Product Build: | 3.0.13 | Resolution: | fixed | ||
| Projection: | none | ||||
| ETA: | none | Fixed in Version: | 3.0.14 | ||
|
|
|||||
| 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: | |||||
| Relationships | |||||
| Attached Files: | |||||
| Notes | |||||
|
|
|||||
|
|
||||