Question
HCL Netherlands
NL
Last activity: 16 Sep 2020 20:30 EDT
SLA Agent processing queueing items in Same Thread
We are updating work objects from the SLA Escalation Activity.
In the SLA Activity, we are creating a standalone PageList getting (which we are not removing) and updating the workobjects from this standalone pagelist values.
Standlone Pagelist means not under pyWorkPage, it is one of the page under UserPages in Clipboard.
Problem we faced is this standlone pagelist is not removed and same pagelist exists for every queueitem.
For Example, Queue Item 1 - PagelistA is created with 1 page in it PagelistA(1).Property1
Queu Item 2- PegalistA created in previous queue item 1 getting carried over to QueueItem 2. So Pagelist A is getting appended with another page PagelistA(1).Property1, PagelistA(2).Property1 like this instead of having only one page which we set in this QueueItem2
P.S: We know as a best practice we always have to remove standalone pages/unused pages after the processing is done.
We are currently getting this issue in Pega 8.4.2 but not happening in version 7.3.0
Question: Will Standard Agent processes queue items in a thread and reuse same thread for other queue items also?
***Edited by Moderator: Pallavi to change content type from Discussion to Question***
Pegasystems Inc.
AU
@VenkataGangadharY4361
Yes I have found a single 'run' of an Agent - Standard or Advanced - runs as a single Interaction on a single Thread in a single Requestor, regardless of how many queue items it works on. I've not used Queue Processors or Job Schedulers enough yet to know if they deal with this differently.
So as you have suspected you need to do, your Agent Activity should have a clean up phase to clear state created by Queue Item N so as to not influence the execution of Queue Item N+1.
Note that this also applies to Requestor- and Thread-scoped Data Pages. As an Agent run executes all Queue Items in the same interaction, even a Refresh Strategy of "Reload once per interaction" will not reload if the same data page (with the same parameters) is referenced by multiple Queue Items in the same run of the Agent. Hence that Data Page may continue to serve data loaded during Queue Item N when it was expected to reload for every Queue Item.
A good practice for Agent Activities would be to - as part of cleanup - call pzFlushDataPage for all the Thread- and Requestor-scoped Data Pages that Activity might have referenced which if referenced in future Queue Items may return inappropriate or out of date data.
@VenkataGangadharY4361
Yes I have found a single 'run' of an Agent - Standard or Advanced - runs as a single Interaction on a single Thread in a single Requestor, regardless of how many queue items it works on. I've not used Queue Processors or Job Schedulers enough yet to know if they deal with this differently.
So as you have suspected you need to do, your Agent Activity should have a clean up phase to clear state created by Queue Item N so as to not influence the execution of Queue Item N+1.
Note that this also applies to Requestor- and Thread-scoped Data Pages. As an Agent run executes all Queue Items in the same interaction, even a Refresh Strategy of "Reload once per interaction" will not reload if the same data page (with the same parameters) is referenced by multiple Queue Items in the same run of the Agent. Hence that Data Page may continue to serve data loaded during Queue Item N when it was expected to reload for every Queue Item.
A good practice for Agent Activities would be to - as part of cleanup - call pzFlushDataPage for all the Thread- and Requestor-scoped Data Pages that Activity might have referenced which if referenced in future Queue Items may return inappropriate or out of date data.
A good practice for Thread-scoped Data Pages would be to include the Case ID as a parameter, even if the parameter is not passed to any of the rules the Data Page invokes for loading/saving. This ensures the Data Page is cached in line with how you likely intended it to be cached, i.e. use it while I continue to care about C-1, when I move onto C-2, load a fresh copy of it.
Even though typical case management usage will generally limit a Thread to a single case, bulk-processing scenarios like (but not limited to) Agents can invalidate any assumption that a Thread-scoped Data Page is bound to the case in the current Thread.