CAFE - Users unable to log off

[RJ!]

Hi Guys,

Has any one had issues with Users unable to log out of CAFE properly?

We had a user lock up our TM1 Server after loging into CAFE, build a crosstab, then closed Excel. They have then gone back in & logged in again, this time the Log Off button is now greyed out.

I've managed to replicate this by loging on & off a few times & monitored it via TM1 Top, each login creates 2 sessions. After about 4 logins/Log Offs, I built a cross tab, refreshed it & then logged out. When I then try & refresh again, it prompts for Username & Password but the splash screen never closes & TM1 is effectively locked up.

I've logged a PMR with IBM in the mean time, just wanted to know if anyone here has experianced similar?

FYI - I've noticed similar persistant Session ID's while toying with the REST API URL's...

[lotsaram]

FYI - I've noticed similar persistant Session ID's while toying with the REST API URL's...

We have also noticed this bug that connections from the Rest API are persistent and never get logged out regardless of the IdleConnectionTimeout setting. Apparently its a bug that should have ben addressed in a 10.2.2 FP or HF but I don't know which one.

[BrianL]

We have also noticed this bug that connections from the Rest API are persistent and never get logged out regardless of the IdleConnectionTimeout setting. Apparently its a bug that should have ben addressed in a 10.2.2 FP or HF but I don't know which one.

Rest API sessions are managed by the tm1s.cfg param HTTPSessionTimeoutMinutes. There's more info towards the bottom of this page: https://www.ibm.com/developerworks/comm ... on%20modes

[BrianL]

TM1 is effectively locked up.

Is the entire server locked up or just the individual user?
Does TM1Top show lock contention (wait states)?

[RJ!]

What we have observed is that a User can log on & log off without the session closing in TM1 Top, if they do not try to action anything via CAFE, they just remain Idle.

We have had 2 instances where the Service has been locked/performance affected from CAFE users doing our testing.

The first incedent was when one of our testers logged into CAFE, created a few Crosstabs & refreshed them, we assumed all was good. We then pulled a large view from a cube, this took some time & we decided we didn't really need to look at that view so then closed Excel (i.e. crashed out). This left the CAFE session still trying to resolve the original View query. This was around 11am in the morning, the Service seemed fine for the rest of the day. Next morning we come in & all of our overnight chores still hadn't completed. We then checked TM1 Top & noticed the REST connection from the CAFE query the day before with 50,000 or so seconds showing. At this stage no one was able to log into TM1 & eventually we had to do a hard restart of the TM1 Service (i.e. not via IBM Cognos Configuration).

The 2nd instance was during my testing to try & replicate the issue above in our Development Environment. As I stated above, loging in & loging out multiple times and then doing a Refresh of an exisitng Crosstab query prompted for a Name/Password that locked up my Excel session + the TM1 Service.

At both of these times I don't recall seeing a "Locked" status in the TM1 Top, just the REST API trawling though 1 dimension as if it was in a loop of some sort.
I'm sure if we left the Service alone, the Chores would have eventually completed, but they would have taken an unacceptably long time to complete!

[RJ!]

FYI we have all of the latest FP & HF on the server & Client side - still having issues with this.

Have given IBM another kick to look at this again for us, let me know if you want the PMR number

[BrianL]

I'm still a little confused.

It sounds to me like you are having two seperate issues.

1. CAFE isn't logging out users from TM1
2. A REST request to the server is running for a very long time and locking everyone else out

I assume issue #2 is the bigger issue. I'd suggest using some form of TM1 logging (API perhaps?) to identify what that REST request is and why it might be running so long. Also, you should use standard lock contention techniques to identify the actual cause of contention.

[RJ!]

Hi Brian,

They seem to be associated issues, it's a very easy issue to replicate. All you need to do is Login to CAFE, press the Log Out button, do this a few times, then try and execute a Crosstab refresh...

If you think about it, how often do you get impatient users that will press buttons when not imediately presented with login screens?
We were given the instructions of adjusting the idle time but this is unworkable as per the scenario above as by the time we've identified the REST session as being an issue, it's already created the REST request that will evenually lead to all processes/chores hanging.

Yes we are aware that you can login as Admin and boot them from the Server Manager, but this relies on us being made aware of the issue before it causes issues...

[RJ!]

Rest API sessions are managed by the tm1s.cfg param HTTPSessionTimeoutMinutes. There's more info towards the bottom of this page: https://www.ibm.com/developerworks/comm ... on%20modes

This does not seem to apply to CAFE...

Even though this issue was "resolved" in FP3, if you log out & then log back in, you end up with the mulitple Instance ID's and are back at square one...

[tm1ist]

I have faced the similar problem and I am given an interim fix which is now included in FP3. After installing the IF, my problem was 'mostly' solved. When a user logs out, the thread in TM1Top is not removed immediately but after around 20 mins(although the fix is supposed to remove it immediately).

RJ!,
Does your issue remain exactly the same after FP3 or changed somehow? Do you too have that 20 min delay for a thread to be removed?

[RJ!]

With the new FP3 change, the first time a user logs out from CAFE, the instance is remove almost instantly.

If they then try to log back in, 2 instance are created. Heaven forbit they get a sticky "login" screen (i.e. remains after pressing submit) and press "Login" a few more times for good measure, you can soon end up with 10+ instances for that user.

Though I did notice that the additional Instances are cleared from TM1 Top after about 5mins or so (maybe less) and I have not managed to lock up our Server yet, so I guess you can say the fix has been successfull...

Still very wary of having CAFE in Production if that potential to crash is there.

[RJ!]

Not sure what changed, but we are no longer seeing the obsolete threads clear out of TM1 Top, they are now persistant until I clear them by booting off the client from TM1 from an Admin login.