TM1 Forum

Hi all,

We are using TM1 10.2. The TM1TOP shows the repeated logins. Even the user has been logged out, TM1TOP still shows the user as login. How to let TM1TOP reflect the real users login status?

Thanks.

Best regards,

Learn_TM1

TM1Top shows current user threads on the server. Depending on various factors like what client tool is used and how, there can be more than one session opened per user. As long as such session threads are shown in TM1Top a given user stays logged on. Sometimes, even if a user closes their client application the session can remain open on the server. You can use the server parameter IdleConnectionTimeOutSeconds to control the time after which zombie threads get terminated.

To provide more help we'd need more info on what exactly you are observing (including what client tools are used and how) and why you think it's a problem.

Hi qml,

Thanks for your reply. The client application is Perspectives. Some users also use TM1 Web. This problem bothers me, because there are so many dead sessions showing in TM1TOP so that I can't find out which user is active.

Where to set parameter IdleConnectionTimeOutSeconds? If this parameter is set as, for example, 1 hour, will be user logged out from Perspectives, or just TM1TOP doesn't show this session?

Best regards,

Chunyan

Are you by any chance using CAM for authentication? There can be a few reasons why the BI Runtime would not properly close TM1 connections when a user attempts to log off. There are way fewer reasons why this would occur when using native TM1 authentication.

IdleConnectionTimeOutSeconds needs to be set in the tm1s.cfg file. It does actually kick users out after a period of inactivity, so in your example if you set it to 3600 seconds then any user who would leave their Perspectives session idle (i.e. not interacting with the server in any way) for an hour would be logged off and would need to log back on.

I am not sure if we are using CAM for authentication. The relevant settings in the cfg file are:
SecurityPackageName=Kerberos
IntegratedSecurityMode=2

The comment shows that 2 is used for integrated and native authentication.

If I add
IdleConnectionTimeOutSeconds = 28800
to cfg file, which means after 8 hours idle, the session will be cut. Should I restart TM1 service to enable the setting?

So it looks like you are using native TM1 authentication and I must say I have not seen a problem with zombie threads with native authentication, with the exception of some old defective 9.x version. Maybe someone else has seen this in 10.2.x and can comment.

Edit: Are you really on 9.4? I've just realised that's what your profile is saying. If yes, you should upgrade.

Learn_TM1 wrote:Should I restart TM1 service to enable the setting?

No need to restart the server. This is a dynamic parameter that kicks in within a minute of updating the config file.

Hi qml,

Thanks for your responds.

Our TM1 is version 10.2.2. When we used TM1 9.x, TM1TOP works correctly.

Best regards,

Learn_TM1

Learn_TM1 wrote:When we used TM1 9.x, TM1TOP works correctly.

Let me repeat once again, in case you missed it. You do not have a problem with TM1Top. Rather, you have a problem with user threads not being terminated properly.

Are you using CAFE?

We had Zombie threads from CAFE Users until we went to FP4 of the latest build.

qml wrote:

Learn_TM1 wrote:When we used TM1 9.x, TM1TOP works correctly.

Let me repeat once again, in case you missed it. You do not have a problem with TM1Top. Rather, you have a problem with user threads not being terminated properly.

I added
IdleConnectionTimeOutSeconds = 28800

to tm1.cfg yesterday, no service restart. But the idle user threads are still on TM1TOP today. It seems that we have this problem for long time, when we used TM19.4. So we restarted tm1 service every night to force the idle user threads to terminate.

Should I add something more in tm1.cfg other than IdleConnectionTimeOutSeconds = 28800?

Thanks.

Learn_TM1 wrote:Should I add something more in tm1.cfg other than IdleConnectionTimeOutSeconds = 28800?

Nope, that's it.

If this isn't working, I would switch the performance monitor on and check in }StatsByClient if you see any traffic from the users whose sessions are overstaying their welcome. I would also check if their status in }ClientProperties is showing as active.

But the bottom line is that it looks like you've hit a defect. Have you checked if the same problem occurs in your non-prod environments? Have you tried upgrading to a later FixPack?

Hi qml,

Thanks for your responds. I only tried it in test environment. If it works, I will bring it to prod environment. I am sure that this user is not active on test environment, because he is on vacation for one week.

We are using TM1 10.2.2. There is already Fix Pack 5 released. Are there some risk if we install Fix Pack 5?

Best regards,

Learn_TM1

Learn_TM1 wrote:We are using TM1 10.2.2. There is already Fix Pack 5 released. Are there some risk if we install Fix Pack 5?

In fact, there is already an FP6 released. And yes, every change has a non-zero risk associated with it, so a full round of regression testing in dev/test is in order before you upgrade production.

SInce you're on a relatively new version of the software, why don't you raise a PMR and see what IBM tell you?

Thanks qml.

I will raise a PMR to IBM.