Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Invalid
-
Affects Version/s: 1.8.1
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
-
Environment:Linux 2.6.18-92.el5 Oracle Unbreakable Linux
Glassfish 2.1
Description
1) when a user is not logged into our system (ie, displaying the login page), we're defining a default timeout period of 30 minutes (a value of 1800 into the setMaxInactiveInternal method)
2) once a user has successfully logged into our web application, we want to define it to a custom value, or if none defined default to an indefinate period
So, once the user successfully logs in, our application checks for a local setting. If none is provided, the application will default to indefinite timeouts by passing a -1 to the setMaxInactiveInternal method for the HttpSession.
However, the value never stays set to -1. It is always being set back to 1800. If a positive value is defined, then it does not get set back to 1800
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
I've cleaned this up, so there's no duplication of code. The previous one had problems with it. Use the v2 patch instead of the first one
With the changes made for ICE-4939, these changes are not necessary. Defining a value of -1 will make a session indefinate. This issue can be closed.
Hello. My previous comment thought that ICE-4939 fixed this. But we've encountered it using 1.8.2 EE Patch 1. We've been able to apply the same patch already assigned to this issue to fix this. So, my request to close this issue was premature. We're still encountering this problem on unpatched releases of ICEfaces. Thanks.
Marking as Closed / Invalid as part of legacy ICEfaces 1.x, 2.x JIRA cleanup.
Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf
If the issue persists with the current ICEfaces release, please create a new JIRA for it.
I've looked into this, and have a solution that works for me. It looks like the Monitor.isExpired() method is causing my grief. It was
public boolean isExpired() {
long elapsedInterval = System.currentTimeMillis() - lastAccess;
try {
int maxInterval = session.getMaxInactiveInterval();
// 4496 return true if session is already expired
Object o = session.getAttribute(POSITIVE_SESSION_TIMEOUT);
// Try to reset the max session timeout if it is -1 from a Failover on Tomcat...
{ session.setAttribute(POSITIVE_SESSION_TIMEOUT, new Integer(maxInterval)); }// But if it was originally negative, it should stay that way.
if (maxInterval > 0) {
if (o == null)
} else {
{ maxInterval = ((Integer) o).intValue(); session.setMaxInactiveInterval(maxInterval); }if (o != null)
}
{ return true; }return elapsedInterval + 15000 > maxInterval * 1000;
} catch (Exception e)
}
So, the monitor is persisting the original value in the POSITIVE_SESSION_TIMEOUT session attribute. From the comments, it looks to be added to cater for behaviour in Tomcat, for when a Tomcat failover occurs
. So, based on that, there is an instance where an application has a positive timeout and the Tomcat server hosting fails and the session gets moved to another Tomcat server which doesn't have the correct timeout set up. So this remedys it.
But, it is directly keeping me from what I want to do. And my application is running in Glassfish, not Tomcat and I don't anticipate using failover (for other reasons related to my application, not ICEfaces).
So, I will submit a patch that does the following:
I thought this might be a good direction, as it looks like the Monitor might want to behave differently based on the Servlet Container hosting it. I haven't tried this out in Tomcat or any other container. But, this does allow my Glassfish server to behave the way I want without having to cater for workarounds added to support another container I'm not using.