Posted: 21 Oct 2015 3:40 EDT Last activity: 26 Oct 2015 9:30 EDT
Would you recommend turning off page level passivation?
I'm getting issues with the main thread (OpenPortal) getting passivated when the user is working on a work object for a time greater than the timeout threshold. When the user tries to log out or access the worklist tab (which is in the OpenPortal thread), the user gets an error.
Is a siteminder timeout involved as well, or some other security layer between Pega and the browser ? If so, you may want to use fiddler to verify that no "posts" are being re-sent without their body content, and verify that no posts are being re-sent as "gets". /Eric
You might also consider tuning the time out. If you are finding that it's happening too frequently, extend it. Obviously that will have an impact on things like memory use since you won't have requestors offloading pages to the database quite so quickly, but it will be less of an impact than turning it off entirely.
What type of authentication with PRPC are you using? You mentioned you are not using any security layer between browser and PRPC. So are you using LDAP authentication using a Data-Admin-AuthService? Maybe even desktop level J2EEContext?
Since you are setting a idle authentication timeout of 20 minutes are you expecting that users should have to authenticate again if idle for 20 min? If you have a Data-Admin-AuthService you have a timeout activity probably displaying a smaller login screen? Do users get a basic authentication popup after the idle timeout?
Looks like the problems you are having can be resolved with the usage of a pxSessionTimer section. I can guide you through this implementation once I understand your current authentication method better.
The PRPC UI is very dynamic and uses AJAX calls to get content and insert that content into layers of the user interface. If a user has been timed out the HTML these AJAX responses return can end up being a login screen and not the real content requested. This doesn't end up getting properly put into the layer of the UI and even if it did it would look funky.
The usage of the pxSessionTimer insures that this occurrence does not occur and that after an idle timeout the only requests to the PRPC server to handle the authentication of the user again.
Adding to Mike's suggestion to tune the timeout, I've seen situations that were resolved by changing the timeouts such that the relationships between the timeout quantities were altered. For example, if there were three timeouts, let's say browser, security layer (such as siteminder), and Pega, and browser timeout was longer than the security layer timeout, changing it so the brower timeout is shorter could make things smoother, since the browser timeout handling will be exercised instead of the security layer timeout handling. /Eric
Our access group has a setting of 20 minutes timeout and can't be changed as it would go against our security policies. We're not using Siteminder or any other security layer between the browser and Pega.
If a user works on a WO tab (dynamic tab) for more than 20 minutes, the fixed tabs which are all under OpenPortal thread won't load anymore.
If I click on another tab, I get a "Cannot render section" error. I can't see any errors in the logs though when this happens.
Another error that happens is when I try to log out. This one renders an error in the logs.
Let's suppose you had two timeouts, one in the browser and the authentication one in the access group, and the browser one was smaller than the access group one, and you wanted to see if making the browser one LARGER THAN the access group one would avoid the error you have been getting, but your company policy strictly prohibited you from making the browser one larger. In that case, you may be able to experiment by temporarily making an access group and reducing its authentication value to make it SMALLER THAN the one in the browser just to see if it alleviates the error.
It is also possible that company policy doesn't allow official changes to certain timeouts but may allow specific temporary changes for the purposes of seeing whether it alleviates your error condition. Even if the change is only temporary, knowing that the change alleviates the error can be very useful information towards finding an official solution to the issue. /Eric
>>> Tried it out with the browser timeout set to 30 minutes and the access group is still 20 minutes in a development environment
So it looks like you've tried the browser timeout being larger than the access group timeout. Try the reverse relationship, where the browser timeout is less than the access group timeout. Is the error exactly the same ? (If so, what experiment can you do to get conformational evidence that the new relationship is actually being used ?)
I would expect the error to look quite different for the two relationships, since an entirely different piece of both hardware and software are involved in the timeout ! /Eric