Question
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.
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***
Can you please provide the PegaRULES and PegaRULES-ALERT logs for the same period?
We need to identify the interactions that are causing the PEGA0019 and identify where the time is being spent.
Unless there is a batch requestor you should expect a PEGA0001 or a PEGA0011 for respectively, browser or application requestors, at every interaction end.
Analyzing the sequence of alerts associated to each interaction should help to identify the issue root cause.
Usually database bottlenecks or remote service calls are responsible for similar behaviors but it's hard to tell without reviewing the logs.