Hi Hari,

You are showing three events here: 51155 to 51157.  These are all using the same requestor, H88C77...

Even if you didn't say you were using a mashup I can tell you are using one. So first some back ground on the three events:

These are two separate browser requests associated with these three events.

The first two events are for PRGatewayPing  which is part of the PegaInternetApplicationComposer.js when using IAC and fires this request on the browser onLoad event before initializing the gadget(s) on the page. I can tell you are not using the PRGateway application as this request reached PRPC. When using the PRGateway application this request does not get sent to PRPC. This request is used to determine what cookie should be used for any type of URL encryption that maybe enabled. This activity call does not require authentication.

The third request is for the Code-Security.IACAuthentication and that is the activity defined in your Data-Admin-AuthService probably named IACAuthentication. This processing only gets called when the requestor needs to be authenticated. The browser request is for running the activity for the gadget. It can't run that until the requestor is authenticated.

More about the data:

This requestor is not authenticated yet, <unknown> in the user column. The sever probably sent back a unauthenticated Pega-RULES cookie, starts with {atn} but still ends up pointing to a "H" requestor on the system. If you look in events 51158/9/10, after authentication has run, the User column starts to get populated.

The "existing requestor retrieved" in event 51157 is not part of passivation. This is the next request that is occurring during the load of your gadget. The requestor was established during the PRGatewayPing call but it's not authenticated yet so the engine is running the Data-Admin-AuthService login activity for you before running the gadget processing activity. This is simply saying that this is the requestor the authentication is being run on. There was no time for passivation to occur here, this all happens usually within the same second.

What is the issue you are trying to debug?

From what you have provided here I can basically tell this was not using an old requestor . This looks like the first few steps of a proper authentication that is using a new requestor when using an IAC gadget that does not use the PRGateway application.

That being said it's very common for IAC gadgets to use passivated Pega-RULES requestors and I will explain why.

PRPC uses browser level in memory session cookies, these are in memory only and are associated with the browser .exe. You can't clear these with browser level cache or cookie clears . Once a session is established with PRPC the browser memory is mapping the in memory Pega-RULES cookie to the host and context root of the application. Every request to the same host and context root the cookie will be sent.

To clear the cookie one of two things needs to happen:

1) Server responds setting the cookie to a value of "none".   (PRPC Logoff will set this to none)

2) Close the browser, no more .exe  (Not closing the tab or logging off the primary application when using IAC)

When in the primary application if you navigate away from the IAC gadget that doesn't directly clear the Pega-RULES cookie. So the next time the user accesses the gadget, could be hours or minutes, the same in memory Pega-RULES cookie will be sent from the browser to the server.  If passivation has occurred then the requestor will be retrieved from a passivated state and used.  This isn't a bad state either.