Question

6
Replies
192
Views
Close popover
Anoojit Dhar (AnoojitD)
Capgemini

Capgemini
SE
AnoojitD Member since 2015 11 posts
Capgemini
Posted: September 5, 2018
Last activity: December 26, 2018
Closed

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.

GENERATEDDATETIMEVERSIONCATEGORYMSGIDKPIVALUEKPITHRESHOLDKPIOVERTHRESHOLDSEVERITYSERVERIDREQUESTORIDUSERIDLOGGERNAMESTACKLASTINPUTFIRSTACTIVITYLASTSTEP
2018-08-31 08:50:54.4178Long Requestor TimePEGA001969523560000095235CRITICAL6ea4116b336bd3006b570728845552c5HAC78D26D4C767E7255449C58F6886C77pXYZcom.pega.pegarules.monitor.internal.context.ManagementDaemonImplNAexisting requestor retrievedRule-Obj-Activity:pzGetURLHashesDATA-ADMIN-OPERATOR-ID UPDATEOPERATORID #20131010T173711.855 GMT Step: 1 Circum: 0
2018-08-31 09:00:49.9258Long Requestor TimePEGA00191290745600000690745CRITICAL6ea4116b336bd3006b570728845552c5HAC78D26D4C767E7255449C58F6886C77pXYZcom.pega.pegarules.monitor.internal.context.ManagementDaemonImplNAexisting requestor retrievedRule-Obj-Activity:pzGetURLHashesDATA-ADMIN-OPERATOR-ID UPDATEOPERATORID #20131010T173711.855 GMT Step: 1 Circum: 0
2018-08-31 09:10:44.9968Long Requestor TimePEGA001918858156000001285815CRITICAL6ea4116b336bd3006b570728845552c5HAC78D26D4C767E7255449C58F6886C77pXYZcom.pega.pegarules.monitor.internal.context.ManagementDaemonImplNAexisting requestor retrievedRule-Obj-Activity:pzGetURLHashesDATA-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***

System Administration Support Case Created
Moderation Team has archived post,
Close popover This thread is closed to future replies. Content and links will no longer be updated. If you have the same/similar Question, please write a new Question.