Luminis Platform 4.0.2.0 build 177 - Issue with early user timeouts
Fri, 2008-05-09 12:19 — Robert Ware
We're running Luminis Platform 4.0.2.0 and have a timeout issue in Production, where, despite the setting below, if employees leave their browser sesion idle for about 20 minutes they get a 'Server Failed' of 'Session Expired' message:
configman -g session.employee.timeout
240
We've turned on DEBUG for the session.log and can see that eployees are correctly allocated a 4 hour timeout at login. We can even see them being timed out 4 hours later but, after 20 minutes or so, if they click on a tab, they are kicked out and nothing is dropped in the logs.
Sungard are suggesting that it may be a bug; has anybody else seen anything like this in Luminis 4.* ?
- Robert Ware's blog
- Login or register to post comments
Hack Your Knowledge
Recent blog posts
- Updated to 4.1.22 - Complications
- Time Estimate for Luminis Platform IV Upgrade
- Luminis IV Memory Configuration
- CPIP Novice Looking for HELP!
- Targeted Announcement Permissions and Grants
- Associated Press OSTN Video News Portlet/Channel
- EAS credentials not the same as luminis credentials
- Lumiins start up issues
- Messaging Server Configuration
- User Attributes from Banner
Developer Links
Poll
If there were a Luminis Developers Conference, would you prefer it in -
early spring
14%
late spring
15%
early summer
29%
late summer
8%
early fall
9%
late fall
14%
early winter
8%
late winter
3%
Total votes: 185
Syndicate
Comments
Something to check
I don't know for sure if this is helpful, but I thought Luminis has a session tracking system and Tomcat has another session tracking system. Maybe the Tomcat session timeout is being reached, so the Luminis sessions are also timing out. Did your 4 hour sessions work previously on any Luminis version?
Session tracking
In terms of session tracking, we set DEBUG on for the session.log by editing the $CP_WEBINF/config/cplog4j.properties file and changing this line accordingly:
log4j.logger.com.pipeline.sm.SessionManager=INFO, session
We also collated the catalina.out and catlina.err from the tomcat-cp webserver.
Do you know where the Tomcat session timeout would be set?
We are a new installation, so I suspect 4 hour timeouts have never been working.
Regards
Rob
session timeout params
There are 3 levels of time out that can be set, so maybe 4.0.2 overwrote one? (user, role, system) User timeouts are higher priority than role timeouts, so if User is set, your employee role one will be trumped by it.
I did that once in testing, a long time ago. Did a cptool set user "MyAccount" User.Session.Timeout="some small time" then forgot about. A week later, I was confused why my set timeout commands on test didn't seem to work.... heh. I had forgotten about my personal setting.
Do you have cptool set timeout enabled or disabled? Ours is set for 2 hours, and looks like this:
-bash-3.00$ cptool set timeout
Current user timeout settings: enabled=true min=5 max=120 default=30
Usage: set timeout enable | disable | range []
= Default timeout value (in minutes)
= Maximum timeout value (in minutes)
= Minimum timeout value (in minutes)
And then the role timeouts, did you setup the priority of each role with configman -s session.timeout.role.override.sequence?
session timout parameters
Thanks for the response.
We've no user timeouts set, just role based timeouts.
cptool set timeout is disabled
$ cptool set timeout
Current user timeout settings: enabled=false min=5 max=15 default=15
Usage: set timeout enable | disable | range []
= Default timeout value (in minutes)
= Maximum timeout value (in minutes)
= Minimum timeout value (in minutes)
Role timeout are set up with employee as the priority:
$ configman -g session.*
session.employee.timeout=240
session.student.timeout=60
session.timeout=60
session.timeout.role.override.sequence=employee,student
What we've checked so far
SunGard gave us a very useful list of potential timeout issues to check, which, although they didn't solve our problem, are worth posting here; partly so everybody can see what we've checked so far and, partly, inc case anybody else has an issue with timeouts:
Early timeout in Luminis can be caused by many different factors. Please check the following (1 - 11) on your system: (1) How is your Luminis session timeout set? configman –g session.timeout (2) Have you configured role based timeouts? configman –g session* If so make sure the “session.timeout.role.override.sequence” is set correctly (All role names must be in all-lowercase letters, regardless of the case used when the roles were created. Also there is no space in between the roles just a comma as a separator.) (3) Have you enabled user specific timeouts? cptool set timeout (4) What browser and OS are the users using. We've seen early timeouts with LP III.3.3 in the past when users were using unsupported browsers like AOL or MSN browser. Please make sure your users are using supported browsers only. They can also have a look at the supported browser list themselves by clicking on the "Having problems logging in? Click here." link on your portal login page. (5) Do the users use special tool bars like yahoo tool bar? We’ve seen this causing early timeouts as well. (6) We saw issues when users had installed some security extras provided by their ISPs. You might want to ask them to turn that off just for a try. Do they use any virus scanner or personal firewalls, if so, which and which ISP? (7) For session management to work properly, the timeout for the Web-based external system must be less than that of the Luminis system. E.g. if you are using ME (Messenger Express) the “service.http.sessiontimeout” value on your mail server must be lower than the lowest session timeout value in Luminis. (8) What is the user doing in the very moment the timeout occurs? Working in email, or WebCT? This can be very useful information. ... (Please view Resolution Document for full text) kbtimeout
....All good stuff, although, sadly it hasn't resolved our problem.
(See Solution 1-1KLBTT - early timeouts on portal before actual session timeout: "session has timed out")
session timeout
I thought of one more thing.
Do you have self-service links in the Portal ?
We had issues with our self-service having a very short timeout. What would happen, was a client would click a self-service link, look at something, then go get a coffee. Come back 20min later, click a new tab, and bam, the portal goes to the timeout window.
It turned out that we needed to increase the self-service timeout to match the maximum portal timeout, otherwise, self-service could timeout the portal.
Hotfix on the way
Thanks for the suggestion but there are no self service links in our portal at the moment.
SunGard have informed us that they are spinning a hotfix for this issue, so I'll post the results of that in due course.