A new parameter was introduced to the web config file in 2.0.6 to deal with the timeout. If I may quote:
No, that's not my problem. Though I have been told that I will be getting Windows Server upgrades I do not currently have them. As a result of which I do not use the Docker-based abomination called PAW.The default TM1® Web session timeout is 20 minutes. When TM1 websheets are deployed to IBM® Planning Analytics Workspace, you might encounter TM1 Web session timeouts. You can modify this setting in your environment.
So, IBM, this is you telling me that you have your shiny new parameter working right. Right? RIGHT??As of IBM Planning Analytics Local version 2.0.6, you must not change the session-timeout value in the web.xml file.
So riddle me this. The default tm1web_config.xml had an empty string in it. And the timeout was not 20 minutes, it was barely even 20 seconds. In fact it was as soon as I either clicked on an application folder or breathed on the frapping thing that I would get a timeout message.In IBM Planning Analytics Local version 2.0.6, there is a parameter in the tm1web_config.xml file called HttpSessionTimeout. You can use this parameter to customize the session timeout (in minutes) of the HTTP session for TM1 Web.
If the HttpSessionTimeout parameter is not specified (missing or blank), the value is less than 1 or not a numerical value, the default session-timeout that is defined in the web.xml file is used.
If you are using IBM Planning Analytics Local version 2.0.6 or later, to customize the session timeout for TM1 Web, set the HttpSessionTimeout parameter in tm1web_config.xml. See step 1.
If you are using IBM Planning Analytics Local version 2.0.5 or earlier, to change the default session timeout, set the <session-timeout> parameter in web.xml. See step 2.
So I set it to 60 as per the example, even though I hate timeouts on principle. Still, the very first thing you do after you log in... timeout. I changed it to some astronomical number. Timeout within seconds. I set it to 20. Timeout within seconds.
Thankfully I still had one 2.0.5 instance floating around which actually works and as a workaround I pointed the production web servers back to that.
I haven't raised this as a bug with IBM (yet) because I won't be able to reboot the server until the wee smalls of tomorrow morning and also I want to see whether anyone else is encountering this.