Pega0019 alerts on production , while using Mashup
Hi,
We are observing a high count of Pega 0019 critical alert ( long requestor running) in the production environment. We are using Pega 7.2.2 and have embedded the customer 360 inside the web page as a mashup. On viewing the alert logs we see that the issue is caused by the following 2 activities:
pzGetURLHashes and UpdateOperatorID. The actual step is in the updateoperatorid but is called from the pzGetURLHashes. I would like to know what causes this activity to fire in the first place ? Why is it consuming so much time? We can also see LASTINPUT as "existing Requestor retrieved". Here is the snapshot of the alert for one user.
Hi,
We are observing a high count of Pega 0019 critical alert ( long requestor running) in the production environment. We are using Pega 7.2.2 and have embedded the customer 360 inside the web page as a mashup. On viewing the alert logs we see that the issue is caused by the following 2 activities:
pzGetURLHashes and UpdateOperatorID. The actual step is in the updateoperatorid but is called from the pzGetURLHashes. I would like to know what causes this activity to fire in the first place ? Why is it consuming so much time? We can also see LASTINPUT as "existing Requestor retrieved". Here is the snapshot of the alert for one user.
GENERATEDDATETIME | VERSION | CATEGORY | MSGID | KPIVALUE | KPITHRESHOLD | KPIOVERTHRESHOLD | SEVERITY | SERVERID | REQUESTORID | USERID | LOGGERNAME | STACK | LASTINPUT | FIRSTACTIVITY | LASTSTEP |
2018-08-31 08:50:54.417 | 8 | Long Requestor Time | PEGA0019 | 695235 | 600000 | 95235 | CRITICAL | 6ea4116b336bd3006b570728845552c5 | HAC78D26D4C767E7255449C58F6886C77 | pXYZ | com.pega.pegarules.monitor.internal.context.ManagementDaemonImpl | NA | existing requestor retrieved | Rule-Obj-Activity:pzGetURLHashes | DATA-ADMIN-OPERATOR-ID UPDATEOPERATORID #20131010T173711.855 GMT Step: 1 Circum: 0 |
2018-08-31 09:00:49.925 | 8 | Long Requestor Time | PEGA0019 | 1290745 | 600000 | 690745 | CRITICAL | 6ea4116b336bd3006b570728845552c5 | HAC78D26D4C767E7255449C58F6886C77 | pXYZ | com.pega.pegarules.monitor.internal.context.ManagementDaemonImpl | NA | existing requestor retrieved | Rule-Obj-Activity:pzGetURLHashes | DATA-ADMIN-OPERATOR-ID UPDATEOPERATORID #20131010T173711.855 GMT Step: 1 Circum: 0 |
2018-08-31 09:10:44.996 | 8 | Long Requestor Time | PEGA0019 | 1885815 | 600000 | 1285815 | CRITICAL | 6ea4116b336bd3006b570728845552c5 | HAC78D26D4C767E7255449C58F6886C77 | pXYZ | com.pega.pegarules.monitor.internal.context.ManagementDaemonImpl | NA | existing requestor retrieved | Rule-Obj-Activity:pzGetURLHashes | DATA-ADMIN-OPERATOR-ID UPDATEOPERATORID #20131010T173711.855 GMT Step: 1 Circum: 0 |
We have a requestor timeout set to 15 mins, and have HA enabled in Production. we have requestor passivation persistance to Database. There are in total 8 nodes which are behind a load balancer (f5) which has a timeout of 1 hr.
Any direction where we should triage for this issue?
***Edited by Moderator Marissa to update SR Details***