TM1 Forum

Hi,

I checked a bit the forum and I found similar issues but not for 10.2.2.3 and I can't apply the same solutions.

The issue is this. I have a client that experiences locks in the system that are not permitting the users to log in.
This happens periodically.
At the beginning, it was happening during a chore so I thought th chore was containing something like securities updates or similia.
I switched off all the chores and weirdly the lock happened again, this time (and a couple of times after), it locked on a user log in (so the log in of a user was not allowing the other users to log in, not always the same user locked the others).

I noticed also that the system is creating zombie threads, meaning that if I open op console or tm1top (shhh don't tell IBM it still works) I can see idling thread from some users that are idling since days and I cannot kill. I assumed these zombies are generated when a user reaches the timeout but I have no proof for that.

Any ideas? could it be that the old issue of 9.5 of the unregistered changes to views after a timeout is still there in 10.2.2.3?

Wat's your IntegratedSecurityMode?

Have you tried switching on lock exception logging in tm1s-log.properties? Have you tried the following config parameter? It is meant to prevent locks on logoff, but maybe it could help in your case. TM1top still works because the API interface for it is also used by the OpsConsole. Nota bene, TM1top is officially back as of 10.2.2 FP4.

qml wrote:Wat's your IntegratedSecurityMode?

integratedsecuritymode 5 integrated login

qml wrote: Have you tried switching on lock exception logging in tm1s-log.properties?

Code: Select all

log4j.logger.TM1.Lock.Exception=DEBUG

Have you tried the following config parameter? It is meant to prevent locks on logoff, but maybe it could help in your case.

Code: Select all

KeepPrivateSubsetsLoaded=T

sadly I cannot stop the system at the moment but I can ask and put it up.

Is the Keepprivatesubsetloaded still a valid parameter in the CFG file for 10.2.2.3?

qml wrote:TM1top still works because the API interface for it is also used by the OpsConsole. Nota bene, TM1top is officially back as of 10.2.2 FP4.

yep, read that just after I posted this post. it is a really good thing.

stingo wrote: sadly I cannot stop the system at the moment but I can ask and put it up.

Is the Keepprivatesubsetloaded still a valid parameter in the CFG file for 10.2.2.3?

The logger update does not require a reboot, but KeepPrivateSubsetsLoaded will. Yes, the parameter is still valid.

stingo wrote:integratedsecuritymode 5 integrated login

That is a very important piece of information. CAM logons seem to cause more locking than native logons, I imagine mostly due to the fact that users' security needs to be updated. The logger should tell you what objects you're getting locks on and we can take it from there.

As to your 'zombie threads' it might be due to Cognos not closing the sessions. Check your Ping timeout in seconds and Inactivity timeout in seconds parameter values in Cognos Configuration.

qml wrote:

stingo wrote:integratedsecuritymode 5 integrated login

That is a very important piece of information. CAM logons seem to cause more locking than native logons, I imagine mostly due to the fact that users' security needs to be updated. The logger should tell you what objects you're getting locks on and we can take it from there.

As to your 'zombie threads' it might be due to Cognos not closing the sessions. Check your Ping timeout in seconds and Inactivity timeout in seconds parameter values in Cognos Configuration.

just a last question before putting the brain at work, will the debug on the log properties degrade the performance a lot?

stingo wrote:just a last question before putting the brain at work, will the debug on the log properties degrade the performance a lot?

Not the one I suggested. It should produce very little additional output: basically one line for every encountered lock conflict. If you switch on a bunch of verbose loggers like the API one, you can expect some performance degradation, but log4j.logger.TM1.Lock.Exception is safe in that respect. Personally, I would also set each logger to print out to its own separate file to avoid flooding tm1server.log. Let me know if you need instructions how to do it.

qml wrote:

stingo wrote:just a last question before putting the brain at work, will the debug on the log properties degrade the performance a lot?

Not the one I suggested. It should produce very little additional output: basically one line for every encountered lock conflict. If you switch on a bunch of verbose loggers like the API one, you can expect some performance degradation, but log4j.logger.TM1.Lock.Exception is safe in that respect. Personally, I would also set each logger to print out to its own separate file to avoid flooding tm1server.log. Let me know if you need instructions how to do it.

sorry for my ignorance but the server is on many machines... where should it be? in local TM1 or in BI?

EDIT: I am a loser... I found the way, google is my friend!

EDIT2: still I would like that suggestion in how to declare another log file as per quote as I cannot find it in the documentation.

qml wrote: log4j.logger.TM1.Lock.Exception is safe in that respect.

From 10.2.2.4 Fix list:
PI42411: TM1 SERVER CRASH WITH TM1.LOCK.EXCEPTION ON

silw wrote:

qml wrote: log4j.logger.TM1.Lock.Exception is safe in that respect.

From 10.2.2.4 Fix list:
PI42411: TM1 SERVER CRASH WITH TM1.LOCK.EXCEPTION ON

ok... maybe I should wait for the patch to be installed then...