Question

What is pzUnknownSessionAlert in Pega 7.1?

My application is built on IAC and uses siteminder for authnetication. At times get an error and I see that the response for the Display Harness is pzUnknownSessionAlert. I am not sure why Pega will throw this error.

I think the issue occurs when I login and logoff with different user ids at some random point it throws the error.

Any help would be appreciated.

***Updated by moderator: Lochan 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.

Comments

Keep up to date on this post and subscribe to comments

September 21, 2014 - 5:55pm

We do use IAC but never came across this error. Does this error get displayed in the UI ?

September 21, 2014 - 8:06pm
Response to HARIKUMAR_ALAMPURU

I get null on UI. PzUnknownSessionAlert has a javascript to throw the user back on login screen which is the gatewayURL/systemid which throws null.

Thanks,

Niren Sinha

Pega
March 17, 2015 - 1:13pm
Response to NirenSinha

Hello- I am moving your question to the Pega Product Support community where it will have better visibility for replies.

Thanks,

Amanda

March 18, 2015 - 9:21am

I am not sure if the following is the fix but i have seen the error ever since.

After calling the logoff script for PegaIAC, logoff from the prgateway too using the logoff.jsp under the war file.

March 18, 2015 - 9:36am

We have an SR on this open, actually. Let me paste my latest comments there:

It is related to High Availability support, we learned -- which we haven't enabled.

Running into this another app, so it might be related to Siteminder.

Here's where we're seeing this.

1. Upon initial login (unsure of prior activity -- presumably a bunch of testing) -- this was the initial problem we found.

2. Locking case on server A, and then on server B trying to get the lock for that case -- killing session A. (see How to avoid message "Unable to unlock work object"? )

While #1 is general fear,

#2 is less likely - and yet it's consistently reproduced. The message makes sense: the session is killed (but why go nuclear? can't we just release the lock and keep the session?).

And yet the pzUnknownSessionAlert's behavior is to auto-refresh itself, which is not what we want, so our overridding rule prevents that.

How is this supposed to work? I think I've seen, that outside of an SSO context, the Pega session will self-close upon getting the InvalidSessionAlert's ajax back ({"invalidSessionAction":true,"pxReqContextPath":"/ampa","pxReqServletNameReal":"smauth"} )

In our scenario 2, here's our session names:

Server A session is H346B07CB18503395B7DA99E1DFE15A44

Server B session is HC920E9D214D0DAE99DFF4A50AFD4BC93

Here's what we see in the logs in an INFO message from HttpAPI:

Found requestor mapping H346B07CB18503395B7DA99E1DFE15A44 -> H1487CCAE98DEB389ADD3F348969696E3

So what is H1487CCAE98DEB389ADD3F348969696E3? Pega creates a session ID if it doesn't have one. In this case, the Browser is still sending the old key, H34.

Why doesn't Pega offer a new session cookie for the browser here?

The H148 session is a dead letter, since it's unauthenticated.

Is there a JMX way to list these session requestor mappings, to understand what's in there?

March 25, 2015 - 10:37am
Response to JonnyGar

Hi Jon,

Can you explain me in detail how to reproduce scenario 2 causing invalidSessionAlert's ajax callback ({"invalidSessionAction":true,"pxReqContextPath":"/ampa","pxReqServletNameReal":"smauth"} )? Do you have any any passivation setting in prconfig.xml?

-Adi

March 31, 2015 - 9:41am
Response to AdityaSirohi930765655

Hi,

I could reproduce the JSON error, this is enhancement to gracefully exit on failover during UI AJAX requests. The way i reproduced it:

  1. Login into Pega developer portal.

  2. From a different tab login to SMA requestor management page and kill the stop the current browser requestor.

  3. In the Pega developer portal try to search for rule of any type and you would see the JSON "invalid session" error.

Can you check if your requestor got passivated and purged by passivation deamon?

April 6, 2015 - 5:31pm
Response to AdityaSirohi930765655

I think I'd tried that, and I took notes down on that, but in another place. This investigation led me here -- When are passivated requestors restored?

I'll have to look at this again, tracking the passivation operations in the logs.