Has anyone experienced passivation errors with SAML Login?
I have not heard of user complaints, however we are seeing a number of these errors on a daily basis Cannot restore passivated page 'AuthReqContext' for Thread STANDARD( full java stack is below),
Note that this page is created by pySAMLWebSSOAuthenticationActivity and is used during the login process. Our timeout settings for users is set to 4 hours. I am wondering if, conceivably users are logging in, the AuthReqContext page is, after 15 min time or so, getting passivated, then if a user has been idle, the system tries to restore the page during the timeout re-authentication process? I do not see any PDN articles specific to this page being passivated. I wonder if the solution to this would be to simply put a page-remove in the pySAMLWebSSOAuthenticationActivity to remove that page once log-in is complete?
Caused by:
com.pega.pegarules.pub.PRMissingContextError: Cannot restore passivated page 'AuthReqContext' for Thread STANDARD
at com.pega.pegarules.session.internal.mgmt.base.ThreadPageDir.checkForPassivatedPage(ThreadPageDir.java:636)
at com.pega.pegarules.session.internal.mgmt.base.ThreadPageDir$PageActivationPassivationListener.onBeforeAccess(ThreadPageDir.java:320)
at com.pega.pegarules.session.internal.mgmt.base.handler.AbstractPageHandler.onBeforeAccess(AbstractPageHandler.java:103)
at com.pega.pegarules.session.internal.mgmt.base.handler.UserPageHandler.getPage(UserPageHandler.java:153)
at com.pega.pegarules.session.internal.mgmt.base.AbstractPageDirectory.getUserPageInCurrentDir(AbstractPageDirectory.java:189)
at com.pega.pegarules.session.internal.mgmt.base.AbstractPageDirectory.getPage(AbstractPageDirectory.java:1061)
at com.pega.pegarules.session.internal.mgmt.base.AbstractPageDirectory.getDirectPage(AbstractPageDirectory.java:672)
at com.pega.pegarules.session.internal.mgmt.base.ThreadPageDir.getDirectPage(ThreadPageDir.java:473)
at com.pega.pegarules.session.internal.mgmt.base.ThreadPageDir.getPage(ThreadPageDir.java:431)
at com.pega.pegarules.session.internal.mgmt.PRThreadImpl.getPage(PRThreadImpl.java:513)
at com.pega.pegarules.session.internal.mgmt.Executable.findPage(Executable.java:2028)
at com.pega.pegarules.session.internal.mgmt.Executable.findPage(Executable.java:1981)
at com.pegarules.generated.activity.ra_action_pysamlwebssoauthenticationactivity_02ab975d06af72caead767130cb77400.perform(ra_action_pysamlwebssoauthenticationactivity_02ab975d06af72caead767130cb77400.java:157)
at com.pega.pegarules.session.internal.mgmt.Executable.doActivity(Executable.java:3375)
at com.pega.pegarules.session.internal.mgmt.authentication.AuthenticationUtil.runActivity(AuthenticationUtil.java:208)
at com.pega.pegarules.session.internal.mgmt.authentication.SchemePRCustom.authenticateOperator(SchemePRCustom.java:695)
Message was edited by: Lochan to add Category
Hi Kevin - we are on PRPC 7.1.7 I can look to see if there are passivation errors for that daemon. I am curious though, couldn't we just remove that page entirely at the end of the activity?
I don't see a Page-Remove on AuthReqContext. We have seen similar issues in Pega 717, i.e. "passivated page could not be restored" and some of them fixed in Pega 718. You may want to open a SR with GCS to get these HFIXes in Pega 717 and this issue investigated, if they are needed.
Just to clarify, these are the fixes for core engine passivation logic, not specific to SAML. I checked the code in 7.2, there is no page-remove for that page either. So that may be necessary. Santosh Das, can you confirm?
If so - I could just update that activity in a local ruleset and make the change.
Maybe you cannot do that, as some dependency might be looking at that page..
I agree with Kevin that these errors are not specific to SAML processing but I think Michael has a point here that we need not have the page floating around for it to finally get passivated.
I think an SE needs to be raised as I see other pages too like LoginInfo,AuthRequestContext etc
The page AuthReqcontext contains a large amount of Data , particularly the Authentication request message as a whole.
The storing of Authentication request message is not longer done in 7.2.1 as part of performance optimization.
.
Should I open an SR then pointing to this and then, in parallel put a step in the activity to remove that page?
go ahead with the SR for further investigation.
Hi Michael Mueller,
When you've opened the SR please reply back to this thread with the SR number so that we can connect this Mesh Post with the SR.
Thanks!
My apologies for the delay. I have created SR-A24408 for this issue and have cross-referenced that SR to this mesh post as well. At this point, I can update the authentication activity to do the page-remove, I just need to know where that makes the most sense. Otherwise we would need this as a hot-fix. Thanks!
Hi Kevin - I have just completed creating SR-A24408and have pointed to this MESH post in the description as well.
I have created an SE - waiting for approval. I suspect the page is being activated when the next user logs in after it was activated. Would it make sense to do a Page-Remove before a Page-New.
Oh - you think a new user is opening the same page as used by a person who has previously logged in. So doing the page-remove would then cause the system to not try to restore the page for the page-new? Am I understanding that correctly?
I'm not sure.
The activation is failing during the pySAMLWebSSOAuthenticationActivity activity and its throwing a PRMissingContextError exception. I do see that Pega is performing checkForPassivatedPage() under name 'AuthReqContext' ... sees that it exists and tries to read it with context of the current thread/Requestor.
The developers will determine the cause/solution.
Hello,
Upon reviewing the corresponding SR, we see that it has been resolved. SA-23816 was created as a result of the investigation. Please reference that if you have the same question.
Regards,
Lochan | Online Community Moderator | Pegasystems Inc.
what is your prpc version? This could be due to some passivation error (search for PassivationDaemon in the logs) leading to the page not passivated successfully. Did you see any passivation related error?