Seeing Pega0004 when user accesses attachments list
As part of application, one of the work object has 89 notes, whenever a user is trying to access the history and attachments the application is throwing an alert saying that it's pulling more than 50 MB data -but in db it has only 70 KB including the blob.
select sum(dbms_lob.getlength(pzpvstream)) from pc_link_attachment where pxlinkedreffrom='MYCLASS-WORK P-530133'
and pxObjClass ='Link-Attachment'
bytes – 73800
The Attachment list is populated by a ListView AttachmentListEmbed, which has a custom getContent activity (getContentSpecial) that uses a when rule to control the presence of the Delete Icon. The when rule (Link-Attachment.HaveAttachmentDeletePrivileges ) calls a Rule-Utility-Function (HaveAttachmentSpecificAccess) to check on whether the icon should be displayed..
2014-09-12 07:15:33,715 [ WebContainer : 31] [TABTHREAD3] [CRMP:02.05.28] ( internal.access.DatabaseImpl) ALERT your_host |127.0.0.1 NBKXJXZ - 2014-09-12 12:15:33,715 GMT*6*PEGA0004*50427092*50000000**The number of database bytes input for this interaction has exceeded the WARNING level for Requestor H223F8EC14E713E3DD349B90D6BEB0FA4, operator NBKXJXZ Maximum bytes: 50000000 Actual bytes: 50427092*
Steps to Reproduce
A work object with a great number of attachments (eg 89 ) will cause one extra read of the work object per attachment.
The root cause of this problem is a defect in Pegasystems’ code/rules. The Rule-Utility-Function Pega-ProCom:Default.HaveAttachmentSpecificAccess performs a db.open() on the work object each time it gets called.
This issue is resolved through the following local change: The Rule-Utility-Function ProCom:Default.HaveAttachmentSpecificAccess was copied into a local RuleSet and modified to make use of the existing pyWorkPage (instead of re-reading it from the database).
Published January 31, 2016 - Updated October 8, 2020