INC-201338 · Issue 690896
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-210346 · Issue 709711
Check added to ensure Job scheduler executed only once
Resolved in Pega Version 8.7.2
When Node A and Node B woke up at the same time to start executing the job scheduler, both were attempting to update the "now processing" node ID with their ID but only Node A succeeded. This caused Node B to generate a "lock already held" exception, then Node B would try to release the lock and update "now processing" node ID. If Node A released the lock before Node B tried to, then Node B updated the "now processing" nodeID and executed the scheduler, causing it to be run twice. This double-run has been resolved by adding a check for whether the job scheduler has been executed recently before starting it.
INC-172675 · Issue 649455
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-185322 · Issue 668321
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-186898 · Issue 670313
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-194180 · Issue 704637
GetChildcases handling updated for large numbers of cases
Resolved in Pega Version 8.7.2
When a very high number of child cases being processed contained a wait shape that was dependent on the movement of a parent case, some of the cases were moved to the next step of the flow automatically while others required a manual command to ResumeFlow. In extreme cases where many child cases were waiting, a node crash could occur. This was traced to the pzGetChildcases report having a maximum value of 500 lines, and has been resolved by increasing the maximum number of rows to retrieve to 9999 in the Data Access Tab of the pzGetChildCases report definition. In addition, the pxCheckFlowDependencies activity has been modified to perform with a higher number of cases, and DSS(MaxRecords) logic has been added to split the child cases into multiple queue items for each access group to decrease load on each thread process.
INC-196389 · Issue 690786
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-201335 · Issue 690733
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-194415 · Issue 710824
Improvements for dirty popup
Resolved in Pega Version 8.7.2
Multiple issues have been addressed for dirty popups. 1) While working on an assignment, making a change and then clicking on the left navigation (Home, Dashboard) did not show the dirty pop up as expected, and the change was lost. The dirty pop up did appear on the Cancel button and Actions within the case. This has been resolved by improving the context switching for visibility of the dirty pop up. 2) Attempting to work around the previous issue by clicking "Do not display dirty warnings" only worked the first time it was tried. With this change in place, opening the assignment, making a change, then clicking Home, caused the pop up to appear as desired, but opening the assignment again and making a change, then clicking Home again did not prompt the dirty pop up. This was due to the click handler getting hit twice, leading to the already open dirty dialog being closed during the second call to the function 'isFormDirty' in pzpega_ui_doc_actionRouter.js file, and this has been resolved. 3) When attempting to close the case as a draft, clicking the save button caused the system to keep loading for a few minutes without sign of completing the save process and eventually the browser had to be closed. The content was saved, but the system was not able end the loading screen. This was caused by an incorrect harness context which caused the "SubmitInProgress" flag to be true on the incorrect harness context so the modal was not dismissed. To resolve this, on clicking the "Save" button, after the confirmation modal is closed, the pega.u.d.isDirtyDialogOpen will be reset to false.
INC-211253 · Issue 711279
Improvements for dirty popup
Resolved in Pega Version 8.7.2
Multiple issues have been addressed for dirty popups. 1) While working on an assignment, making a change and then clicking on the left navigation (Home, Dashboard) did not show the dirty pop up as expected, and the change was lost. The dirty pop up did appear on the Cancel button and Actions within the case. This has been resolved by improving the context switching for visibility of the dirty pop up. 2) Attempting to work around the previous issue by clicking "Do not display dirty warnings" only worked the first time it was tried. With this change in place, opening the assignment, making a change, then clicking Home, caused the pop up to appear as desired, but opening the assignment again and making a change, then clicking Home again did not prompt the dirty pop up. This was due to the click handler getting hit twice, leading to the already open dirty dialog being closed during the second call to the function 'isFormDirty' in pzpega_ui_doc_actionRouter.js file, and this has been resolved. 3) When attempting to close the case as a draft, clicking the save button caused the system to keep loading for a few minutes without sign of completing the save process and eventually the browser had to be closed. The content was saved, but the system was not able end the loading screen. This was caused by an incorrect harness context which caused the "SubmitInProgress" flag to be true on the incorrect harness context so the modal was not dismissed. To resolve this, on clicking the "Save" button, after the confirmation modal is closed, the pega.u.d.isDirtyDialogOpen will be reset to false.