| Anonymous | Login | Signup for a new account | 12-17-2024 10:40 PST |
| 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 | ||||
| 0000222 | [Resin] | minor | always | 05-27-05 00:00 | 11-30-05 14:43 | ||||
| Reporter | sam | 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 | |||||
| Product Build | |||||||||
| Summary | 0000222: session timeout issue | ||||||||
| Description |
RSN-245 (rep by B Davis) I tested the latest resin snapshot (050525) and sessions are still not timing out correctly. This is the same issue we reported on March 18, 2005, and is related to the issue we reported as a critical issue on Feb 2, 2005. The behavior has changed somewhat from previous reports in that sessionDestroyed on our session tracking listener after the session timeout specified in the web.xml, however the end result is still the same. Additionally using a debugger, I find that the session timeout in the HttpSession object is set to 60000 milliseconds, which is correct, however the value is clearly being ignored in favor of the default timeout settings of the backing store. Calling session.setMaxInactiveInterval also has no effect. The changes you introduced in this revision are actually worse in that it breaks our only possible workaround of calling session.invalidate() to insure that the session is removed once sessionDestroyed fires. The relevant portion of our web.xml is : <session-config> <!-- <tcp-store/> --> <!-- <file-store>WEB-INF/sessions</file-store> --> <!-- <always-load-session/> --> <!-- <always-save-session/> --> <session-timeout>1</session-timeout> <ignore-serialization-errors>false</ignore-serialization-errors> </session-config> The relevant section of resin.conf is <persistent-store type="jdbc"> <init> <data-source>jdbc/mysql</data-source> </init> </persistent-store> SRV.7.5 Session Timeouts In the HTTP protocol, there is no explicit termination signal when a client is no longer active. This means that the only mechanism that can be used to indicate when a client is no longer active is a timeout period. The default timeout period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface. This timeout can be changed by the Developer using the setMaxInactiveInterval method of the HttpSession interface. The timeout periods used by these methods are defined in seconds. By definition, if the timeout period for a session is set to -1, the session will never expire. The session invalidation will not take effect until all servlets using that session have exited the service method. Once the session invalidation is initiated, a new request must not be able to see that session. |
||||||||
| Steps To Reproduce | |||||||||
| Additional Information | Resin snap 050525 | ||||||||
| Attached Files | |||||||||
|
|
|||||||||
 Relationships |
|
|
Notes |
|
|
(0000255) ferg 05-27-05 00:00 |
server/01o0 |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 05-27-05 00:00 | sam | New Issue | |
| 11-30-05 00:00 | administrator | Fixed in Version | => 3.0.14 |
| 11-30-05 14:43 | ferg | Status | resolved => closed |
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
29 total queries executed. 27 unique queries executed. |  |
