When are passivated requestors restored?
to my recollection, a passivated requestor is restored when a user re-accesses Pega but his session requestor is not in memory, so it's pulled from the database.
One of our 7.1.5 QA systems here has 108 passivated requestors, and 14 active requestors.
I set DEBUG on com.pega.pegarules.session.internal.mgmt.base.NodeRequestorMgt on it.
I see messages at a rate of >3/second telling me "Retrieved requestor: A5D438FE740B5551AAA3584DBBCCEBC64"
Why would it be doing that?
Also, when I look at these A* requestors, they have a number of pages on the Clipboard, like pyResponseAttachmentPage and pySearchPage.
This is created by InvokeHTTPConnector and other connectors. pySearch i used by pySearchHTTPConnect.
This connector has Maintain Session unchecked. So I'd expect this requestor to be deleted after use.
So why is it passivated? And why is it regularly being retrieved, when I turn on that logging?
I can view the Passivated Requestors on the SMA. Is there no way to delete them? I'm wondering if the passivated requestors is related to our problem triggering the pzUnknownSessionAlert stream (see SR-128597 & SR-128894)
***Updated by moderator: Marissa to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Passivation is a vital component of PRPC’s ability to properly operate at scale. Through the removal from memory and temporary storage of inactive user session data (Requestors, Threads, and Pages), a PRPC system can more appropriately utilize its available system resources. Passivation also provides the system with a mechanism for partially preserving user data, which can be used to recover session information in the case of a system failure.
Passivation serves three primary purposes, which are defined as follows:
1. Freeing resources.
2. User session recovery
3. Migrating user between nodes (The passivation system’s ability to migrate user sessions between nodes provides the foundation for PRPC’s High Availability feature set)
Looking at the prefix of your requestor, its an Agent requestor. You are seeing the message "Retrieved requestor: A5D438FE740B5551AAA3584DBBCCEBC64" because the agent requestor is in the node's passivation queue(passivated) when not being used and when your agent is invoked(that how agents are designed to run in certain intervals) then agent tries to access any previously passivated data (Requestor, Thread, or Page), the PRPC node will retrieve the necessary data from the passivation storage mechanism and restore the object in system memory.
You should not had seen those message if an object hasn’t been accessed since it was initially placed in the passivation queue, it is removed from system memory and serialized to the passivation storage mechanism by the PassivationDaemon.
Passivated Requestors on the SMA does not have the MBEAN exposed to provide the functionality to delete requestor yet and its handled by system pulse or the PassivationDaemon.
To debug further:
1. User can enable debugging on requestor lifecyle(will give verbose information of reqestor lifecycle) "com.pega.TRACE.requestor_lifecycle"
2. Is it always the Agent requestor causing pzUnknownSessionAlert?
Keep up to date on this post and subscribe to comments
- com.pega.pegarules.pub.PRRuntimeException: Unable to restore passivated requestor; error in authorization activation
- Unable to restore passivated requestor; error in authorization activation (no legacy context found)
- Unable to restore passivated requestor; error in authorization activation
- Instances of Data- and Embed- can be restored?
- How to turn off Requestor / Thread Passivation in PRPC 7.1.8? Will there be any side effects that are not related to passivation?