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.
SR-119297 · Issue 183495
Dynamic container enhanced for harness sections
Resolved in Pega Version 7.1.8
In some situations, tab visibility conditions were not functioning as expected. For example, in a portal with a harness that has 2 sections, the click of an enable/disable button in the top section was configured to refresh the bottom section as well as call an activity. The bottom section had a tab layout containing harness rules with conditions specified for the tab visibility based on the above "Enable/Disable" button. For the above features, the data model got created when the Dynamic Container was being rendered for the portal's harness, and the data model was updated with the dynamic tabs' meta data. However, the data model was not being created while rendering the harness, and the lower section did not confirm to expectations. To resolve this, the code has been updated to handle the section refresh which has a Dynamic Container.
SR-D28719 · Issue 505967
Null archive check added to set import process status
Resolved in Pega Version 8.2.4
After running a 'prpcServiceUtils.sh import' which failed due to a low-level null pointer error, the job "IMPORTREQUEST-2" then incorrectly showed the status as 'IN PROGRESS' instead of 'FAILED'. In this case, the null pointer exception occurred because two imports were unintentionally happening at the same time: the process copied up the same set of archives to the service export directory, but the first import processed an archive and deleted it so that the second process failed to find it. When it exited with the null pointer exception, the status was not set to 'failed'. To resolve this, a null archive check has been added which will set the status to 'failed' if the archive is unsupported, corrupt, or not there at all.
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.