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?
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)
Accepted Solution
Updated: 11 Mar 2015 16:23 EDT
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.
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?
BNY Mellon
US
Thanks. Yes, of course, passivation has those other uses. And yes, clearly, these are passivated agents.
I'll have to trace requestor_lifecycle on this system -- I just thought that the frequency of Retrieving (is that the same as restoring?) requestors seemed high and worth a look.
BNY Mellon
US
Don't agents start with "B" (for Batch), not "A"?
Spunoff by follow-up question to here: Why are requestors for the pzHTTPLuceneSearch passivated?
Hi Jon, can you send us the PegaRULES logs that has the lines 'Retrieved requestor: A5D438FE740B5551AAA3584DBBCCEBC64"? depending on the context of this log line; It could mean retrieving requestor from the Application Requestor Pool. Thanks!
BNY Mellon
US
I've branched off a separate discussion here: Why are requestors for the pzHTTPLuceneSearch passivated? -- I was less concerned about these requestors getting retrieved than I was about why they were getting passivated in the first place!