There have been several PeopleSoft Timeout problems that have impacted various levels of 8.50, 8.51, and 8.52. Indications are all these problems are fixed now. According to Oracle, the code has also been fixed in 8.50.25, 8.51.17, 8.52.07, and 8.53. I’m sure a new problem will pop up at some point though.
The first problem which I consider the most dangerous, is that the timeout warning process breaks down and causes a users browser to repeatedly request the timeout warning pop-up page. It looks like this particular problem impacts 8.50.22, 8.50.23, and 8.50.24. It looks like it also impacts 8.51.12 – 8.51.16 and 8.52.00 – 8.52.06. I don’t have the 8.51 or 8.52 versions running, however looking at the code delivered in the 8.51.16 and 8.52.06 patches, the problem code does exist. I know 8.52.07 does not have the bad code because I do have access to an environment at that level. This was actually put in as a fix for another problem, which I’ll mention later. It was put into 8.50.22, 8.51.12, and 8.52.00.
Users may have their PC’s hang as the browser takes CPU to 100% requesting the timeout warning page. Or if you have access logging turned on and you review the web server access log you will see hundreds to thousands of requests for the warning page from a single IP repeatedly in quick succession. In some cases this can cause the web server to crash. In other cases I’ve heard of it maxing out jolt connections on the app server. Oracle has a work around posted [ID 1405219.1].
It looks like they used the wrong JavaScript method and instead of using setTimeout() used setInterval(). What then occurs is the user will have a small amount of time left after the original setTimeout() was called. There is an if statement in the code that “if (current time – last access time) is less than (the warning time – a small adjustment)” then call setInterval() for the pop-up with the interval being the remaining time. This is the fix they put in (the if statement was there earlier without the setInterval() call). For some reason certain systems are having time left over and entering this If condition, but in older 8.50 code the loop simply returned thus exiting without displaying the time out window. Well setInterval() runs it’s parameter repeatedly at the specified interval. In order to just delay the pop-up the remaining amount of time it should be setTimeout(). The work around directs you to correct this.
If you are experiencing this first problem. After updating the code on the HTML object PT_SAVEWARNINGSCRIPT you may need to force users to clear their browser cache. I saw this JavaScript being cached on the browser and not being reloaded even though the web servers had been restarted and their own cache cleared. Since there was 4000 users at the site, they changed the cache directory in the web profile to force a new URL which did the trick.
Another problem is that time outs across windows/tabs are not synched. This one I think has existed for a long time actually. Oracle indicates that there was a bug in 8.4x that they did not fix which allowed users to not be timed out of idle windows but since it was a bug, it was fixed in the 8.50 release. I’m not sure what 8.4x releases that bug impacted. Good news is it’s fixed moving forward. Oracle says this about the behavior.
In PT8.4, if end user is active in one browser window, but lets the other window remain idle and timeout, the end user could continue in active window. This was a bug: 11558697 in PT8.4 and incorrect behavior. Many customers prefer the incorrect behavior in PT8.4; however, that behavior was a bug. The timeout behavior in PT8.50 is correct and development will not revert back to PT8.4 timeout behavior.
So with 8.50 users start experiencing timeout behavior they may not have seen before. If your users perform a function that commonly spawns new windows this may impact them. One particular scenario would be they simply missed the timeout warning pop-up and didn’t acknowledge it, they would now be timed out even if they were active in another window. This is corrected now in the newer releases indicated above. They have rewritten the JavaScript to utilize the value of PS_TOKENEXPIRE, which provides a singular Last Access time, across the browsing session. A nice change if you ask me. In fact, since PS_TOKENEXPIRE is shared across all SSO shared environments, that actually allows Portal and Content databases to timeout together, another nice addition. I saw a reference to PeopleBooks 8.53 being updated to specify this, however I wasn’t able to find it yet.
Another more complicated scenario of this problem allows users to be timed out even after clicking OK on the timeout warning window. This probably doesn’t happen all that often but I heard from a previous co-worker that he has had users impacted by this. If you open three windows pretty close to one another and remain only active in the third one and leave the 
other two open, you could fall prey to this. Here’s the details. Window A gets opened with it’s own timeout. 10 seconds later the user then opens window B, also with it’s own timeout. In window B they do something to open window C. They continue to work in window C. The warning will be displayed based on inactivity for window A. If the user does not acknowledge the timeout by the time window B gets to it’s warning time (10 seconds after window A) window B will initiate a new warning. However, the warning from window B won’t create a new window, it will update the existing pop-up from window A. Now we have a problem. Two windows with separate timers will timeout in a few minutes but there is only one pop-up window. My testing with IE indicates the JavaScript will actually reset the timer in window A however the browser will make a GET call for window B. The GET call doesn’t impact the JavaScript timer but it will keep the web server session alive (but your already active in the other window so we are fine there). What then happens is window B will time out shortly leaving the user wondering what just happened? They clicked OK on the warning but still got timed out. As you can see, I tried to present a visual depiction of this process. I’m not very good with those tools so I hope you can enjoy a laugh at my art work.
I’ve also seen reference to some other problems regarding where the setuptimeout() function is called in the JavaScript. But I don’t have too many details on that one, it sounds like they were calling setuptimeout() from code associated with key presses. This did not necessarily make a request to the server. So you could be typing up your performance review for 2 hours and the window would not time out. But once you went to save the review, your session had already timed out, and all was gone. I think even I have been hit by that one before. This also has been fixed with the new code, you’ll be warned about timing out now to avoid your web server session from vanishing. This fix was also supposed to go in with the 8.51.17 / 8.50.25 updates.
Leave a Reply