LinkedIn
Copied!

Troubleshooting PRMissingContextError when restoring passivated pages

Version:

Only available versions of this content are shown in the dropdown

Users see exceptions when passivated pages cannot be restored.

In Pega applications, system administrators use Database-Level Passivation to specify configuration settings to support High Availability, Multiple Nodes in clustered environments, and Quiesce during maintenance cycles. The Pega Dynamic System Settings (DSS) shown here have not changed for many years and are still in force.

DSS database passivation

Single sign-on authentication is configured for all users and passivation is set to use the Access Group and Authentication Service timeouts as four (4) hours for users:

Authentication timeout

You see passivation messages in the logs for a Quiesce Request during a maintenance cycle and under normal timeout scenarios. Periodically, when some passivated sessions or requestors cannot be restored, you see the exception in the logs stating this fact.

Errors

com.pega.pegarules.pub.PRMissingContextError, Cannot restore passivated page ‘OperatorPage’ for Thread: STANDARD Requestor:HR867PB3QV6ZLHQ6MB2Q6CNIS79M77O7NA

com.pega.pegarules.pub.PRMissingContextError, Cannot restore passivated page ‘pyContent’ for Thread: STANDARD Requestor:HDWZLII951SF50Q8CN7E28UDJUJ610F1DA

Steps to Reproduce

  1. Configure a Pega system to use SAML 2.0 authentication.
  2. Set the timeout period for more than two hours.
  3. Log into the application and open one or more landing pages or work objects.
  4. Allow the browser session to be idle for more than two hours (the timeout period specified in Step 2).

    The system will try to re-instantiate the page. In some cases, this fails.

Explanation

Trace back of the first exception indicates that it was thrown from pySAMLwebssoTimeoutActivity, Step 4, and the activity pyEstablishOperatorContext.

Trace back of the second exception indicates that it was thrown from the activity ReloadSection, Step 5, and the activity pzGridSortPaginate, Step 1.

Database passivation of requestors is stored in the pr_sys_context table, and there are agents that clean up (remove) passivated requestors older than 24 hours with no activity. This works as expected without issue. Investigation revealed that PRPC and the Pega Platform also create cookies on the client that are used in the Restoration process. If these cookies, or the contents of the cookies, are removed before a reactivation of a requestor, the restoration might fail. During the life of a requestor, certain cookies must remain available until the user logs off of the Pega Platform or closes the browser. A new requestor session will be created in both scenarios including new cookies.

Solution

If your organization has procedures or best practices to delete cookies when connecting to multiple Pega applications and navigating between these connections in the same browser (multiple tabs), take care not to delete the cookies belonging to the URL of the connected session that remains valid (connected). Doing so will invalidate your current session to that application server and might result in multiple exceptions or features no longer working.

Check for site-specific cookies for Pega applications

Using Chrome as an example, follow these steps to check the cookies of connected sessions:

  1. In the cookies page (chrome://settings/siteData), scroll through the list of cookies to find the URL of your application.
  2. Click the cookie for that URL to open its settings and see what is included.

    There will be several settings that include JSESSIONID, Pega-Perf, Pega-RULES, PegaIAC and possibly one or more for a load balancer or proxy server. Each of these settings contains information used by Pega to determine what is restored as part of the activation process for the requestor. If this information is missing, some or all the pages that were passivated might not be available at the time of restoration or reactivation.

    Pega uses what information it can find and tries to restore what it knows to restore and fails on what it is unable to find. This creates a partially restored requestor, which might (or might not) experience other issues while the application is in this state.

Best Practice

Do not delete cookies of existing, active sessions without first logging off or closing the browser completely (not just a tab), or both.

Selectively delete cookies only to remove entries that are safe to remove.

Each browser type (Internet Explorer 11, Edge, Chrome, Safari, and others) has specific steps to clear, remove, or delete cookies. Refer to the browser’s documentation to learn how to delete a site-specific cookie.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.