How to turn off Requestor / Thread Passivation in PRPC 7.1.8? Will there be any side effects that are not related to passivation?
Our application is deployed in a multi-node high availability system. We are currently writing data to filesystem and that too into Pega Temp directory of that node.
We would like to turn off passivation
I see that passivation can be turned off using the following entry in prconfig.xml:
<env "initialization/persistrequestor/usepagelevelpassivation" value="false" /> -- Page Passivation
<env name="Initialization/PersistRequestor" value="Never"/> -- Requester Passivation
Will this suffice? Has anyone tried this in their production applications? Appreciate any help.
**Moderation Team has archived 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.
Accepted Solution
Updated: 21 Jun 2016 6:08 EDT
Aaseya IT Solutions
IN
We tried disabling passivation and the application did not see any major issues.
Updated: 14 Jun 2016 1:08 EDT
Pegasystems Inc.
US
Hi Raju,
The settings to turn off page level passivation and HTTP requestor are correct.
As per the help article on passivation https://community.pega.com/sites/default/files/help_v718/procomhelpmain.htm
Typically, page passivation improves performance for production systems that may have 50 or more simultaneously connected requestors (not counting agents). For smaller systems (with adequate JVM memory), the benefits may be small or none at all.
Reg timeout requestor passivation, when enabled (through Initialization/PersistRequestor entries in the prconfig.xml or DSS), each HTTP requestor session can be saved after a specific time period of no activity.
You can also let us know why you want to consider disabling passivation? so that other can weigh in here. I guess there are also changes done w.r.t to passivation on high availability systems on latest versions.
Aaseya IT Solutions
IN
Hello Harish
Thank you for the response.
We are currently evaluating the benefits vs performance implications of passivation.
Also, the passivation data is not being cleaned due to a systemcleaner issue.
At this point, i would like to understand if there are any unknown implications of turning of passivation.
Pegasystems Inc.
US
I can't really comment on the implications you may face if you disable passivation. It depends on various aspects.
Regarding the issue -
SystemCleaner agent does the delete of expired passivated requestors data. As per the code, passivated requestor context data is deleted it is older than 2 days. It can controlled by the below DSS setting.
Owing ruleset: Pega-Engine
DSS purpose: prconfig/initialization/persistrequestor/contentExpiryThreshold/default
Value: 36000 (in seconds)
Accepted Solution
Updated: 21 Jun 2016 6:08 EDT
Aaseya IT Solutions
IN
We tried disabling passivation and the application did not see any major issues.
standard chartered bank
IN
Hi Raju ,
Hope doing Good . my observation below FYR
Disable the passivation may not increase the performance(storage) in DB side. Because passivation objects ( Page , Requestor ) are removed from table immediately, if we close the work thread or Log off the requestor properly. Suppose if we close improper mode ( Ex : Directly close the browser session ) for those passivated object instance are not removing from table immediately. But those objects are removed based on System Cleaner agent ( by default 2 days ).
In general passivation concept does not have impact in performance ( Storage) in DB side ( Except query execution ( during passivation and activation ) process , If we enable it increase the JVM performance.
Thanks
Christopher.J
TCS
US
Hi All,
We have similar kind of requirement where we need to delete the idle requestor session history from pega.
For that we disable the persist requestor <env name="Initialization/PersistRequestor" value="Never"/>
But i think this not enough to achieve our goal (To close all active thread after requestor time out ). As we have high availability pega application so by default it store user session data in specific internal database. We thought of truncating .pr_system_cotext and pr _page_store table but we don't know what is the implication of that. So can anyone share their experience who has faced similar thing before?
Thanks in advance.
Regards,
Niladri
TCS
US
Hi All,
We have similar kind of requirement where we need to delete the idle requestor session history from pega.
For that we disable the persist requestor <env name="Initialization/PersistRequestor" value="Never"/>
But i think this not enough to achieve our goal (To close all active thread after requestor time out ). As we have high availability pega application so by default it store user session data in specific internal database. We thought of truncating .pr_system_cotext and pr _page_store table but we don't know what is the implication of that. So can anyone share their experience who has faced similar thing before?
Thanks in advance.
Regards,
Niladri
Pegasystems Inc.
IN