Random session time out in TM1Web?

maxhyip

Hi

We experience problems with session time out in TM1Web. We have gone through some manuals which we found on the web how to change the session time out parameters but couldn't find an answer for the behaviour described below.

Here some facts about the current versions and settings:

Server:
- IBM Cognos Express 10.1
- MS Excel 2010
- OS on server: Windows 2008 R2 SP1, IIS 7

TM1Web:
- TM1 Web is reached via a Citrix client by users
- SSL is used
- Domain name is used to access TM1Web (hostname and domain name have NO underscores!)
- IntegratedSecurityMode = 1
- Session time out has been increased for testing this issue to 2 hours in the following places:
        1. tm1s.cfg (IdleConnectionTimeOutSeconds)
        2. web.config (timeout value and httpRuntime executionTimeout)
        3. IIS (Connection timeout for default web site and Idle-time out for DefaultAppPool)


Description of the issues we face:

1.        Session time out occurs after first opening of changed and republished sheet in TM1Web
-        Session time out error is triggered by a certain action when entering the changed and republished sheet for the first time, e.g. open subset editor or press the button ??rebuild active form?? (it is possible to enter the changed sheet without a session time out, session time out occurs after an action in the sheet like rebuilding the sheet)
-        After logging in again and navigating to the sheet, no session time out occurs anymore when working with the sheet
-        Could not find any helpful information in the web log

2.        Random session time out for users when working in TM1Web (it is probably not random but we haven??t found a pattern/reason for the time out yet)
-        Users get a session time out error which seems randomly (sometimes after 3 minutes, sometimes after 10 minutes etc.). The error suddenly occurs even when actively working with the sheet.
-        I have made a successful test on the weekend (no other users were logged on) where I opened a report in TM1Web, waited more than one hour and pressed ??rebuild active form?? and it worked - no session time out. So in general the parameters changed in the web.config etc. seem to work correctly but there must be something which triggers the session time out.
-        Could not find any helpful information in the web log

Has anybody experienced something like that before or any ideas what the problem could be?

Thanks
Mario

xdd11

I cannot give you a definitive answer but what seemed to work for us was turning off the check boxes on the application pool to recycle the worker processes. This seemed to take care of some of these issues, but I still think there is some strange session mixing that is going on within IIS. We have just gotten into a maintenance pattern where we restart the web servers every weekend to force a recycle so the processes do not grow too large.

As far as a pattern we saw this alot with the web cube viewer and changing tabs to and from a cube view. This could be coincidence but it was what we observed.

We have seen various issues with language localization and other strange web issues that lead us to think that session management between IIS and TM1Web is not ideal.

We spent a good deal of time with IBM on this and that is where we ended up after many go rounds of setting checking and log emailing. If you can get further that would be great, but in the end you are dealing with the black hole that is IIS and how it is managing the sessions.

fs111

Hi George

Thank you for your answer. We discoverd in the web.config that there was a absolute path entered, specifying where the TM1WebEx folder should be located. But the path was wrong and the folder didn't even exist. So all the files where cached in the folder TM1WEBExcelSheets instead of TM1WebEXExcelSheets. We cleaned both folders and restored the default entry which is:
<add key="UseSeparateVirtualCache" value="Y;Url=;AbsolutePath=" />

It seems we made some progress by doing this but we are not 100% sure yet if that solved the problem. We will have to test more.

Regards
Mario