I had an important report recently that required some digging into timeout parameters, and we worked it out, setting the timeouts to 35 minutes, in
Works great and reliable.
Users are asking for 45 or 60 minutes, is there a best practice?
gadsden_consulting 
(BOB member since 2015-06-18)
Here’s some additional details:
The report runs fine, always under 30 seconds. But it’s used for “board proceedings”, where an Academic council reviews up to 30 students’ records, one by one on the report, clicking through each student. Sometimes the review for a student takes 10 minutes. Sometimes it could generate lots of discussion and go 30-40 minutes. Board members all have the report on their laptop. If they sit idle (listening to the discussion) for 35+ minutes, then when they go to click to the next student, the report has timed out.
If they click here and there during the discussion, that of course resets the timer.
So just looking for a reasonable timeout period whereby an idle report would still be active and usable after XX minutes. We’re currently at 35 minutes which is reliable but the board has asked for 45-60 minutes.
gadsden_consulting 
(BOB member since 2015-06-18)
No response in a week, but 128 views. I’m reposting in Building Reports forum.
My take is it’s fine to set timeout settings to 60 minutes - what is the harm (as long as license usage is manageable).
gadsden_consulting (BOB member since 2015-06-18)
My experience is that you will not agree with your users on what is “reasonable” for a timeout. Like you, we have users that want a longer timeout setting. We ended up having to set our timeout settings to two hours because our users wanted to be able to leave for lunch or a meeting and come back and pick up where they had left off without having to log in again. They had enough pull with management that we couldn’t fight this.
It works OK as long as you make sure the sessions do log out after the timeout is reached. When we originally configured this timeout, the Administrator updated the timeout in Tomcat but then disabled everything in Business Objects assuming that Tomcat would timeout the Business Objects sessions, which it didn’t. This of course left sessions hanging out in Business Objects for days.
At our next upgrade, I corrected this and we haven’t seen any real problems from it.
JohnBClark,
great! Thanks for the tips and I will pass this along to our internal review team who’s discussing this.
gadsden_consulting (BOB member since 2015-06-18)
If the system is based on concurrent users, it could become an issue if you make the timeout too long. You concurrent license could be consumed by inactive sessions. Having to pay for more licenses could be incentive to have a shorter time out. We are still on a CPU based license so number of users logged in doesn’t really matter to us.
We do have a couple of users who seem to frequently get “locked up” and clearing their sessions has usually solved whatever they did. I think it is more a user issue than a system issue as only a couple of users have that problem and they usually have more than one session going.
JohnBClark,
very good - yes, license usage is a concern, but so far manageable. The report in question is high usage 5-6 times a year, so we keep our eye on it. At the moment the timeout is the issue, but increasing it will make us keep a closer eye on the usage.
Thanks!
gadsden_consulting (BOB member since 2015-06-18)