Can you tell us what version of Pega you are running?

Please tell us the error and we can decide what should be done.

What does the user see and what is in the PegaRULES log?

Rachel,

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.

Thanks,

Mike

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

Hi All,

We're currently using Pega v7.1.8

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

Hello,

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