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-C36091 · Issue 377696
Stuck run detection improved to give information and stop bad jobs
Resolved in Pega Version 8.1
When a run is in NEW state, attempting to trigger it caused the run to move into the INITIALIZING state and after some time back to the NEW state. Once that happens for the first time, it would continuously happen to the same run and force the creation of a new run. Investigation showed that in very specific situations a data flow run might take too long to initialize. That caused the system mechanism that detects runs stuck in a transitioning state to kick in and move it back to NEW state. Later that run would actually be initialized but its status would no longer be reported correctly, giving the impression that the run was always going from NEW->INTIALIZING->NEW. To prevent confusion, code has been to the stuck run detection that will add troubleshooting information and stop that run if it's in a state that was was not anticipated.
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.
SR-C48633 · Issue 390528
Missing rules will be inserted into pr4_rule_vw table
Resolved in Pega Version 8.1
On running ExposeCols from prpcutils, if pr4_rule_vw table was truncated or had some rules missing, then the records were not being updated. Logging indicated there were view rules which were present in pr4_rule_vw but not present in the actual class, causing a duplicate key exception when the system tried to insert the same rule again into the pr4_rule_vw table. Previously, ExposeCols functionality always updated the rule record and its corresponding Data-Rule-Summary record but would never insert a new rule or Data-Rule-Summary record. This meant that if the pr4_rule_vw table was truncated before running the column expose, none of the rows were getting updated as the table was empty. To resolve this, if the rule is missing in the pr4_rule_vw table, insert queries will be executed and the rule will be populated in the corresponding Data-Rule-Summary record.
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.
SR-C6567 · Issue 352049
Enhancement added to customize Cassandra consistency level
Resolved in Pega Version 8.1
Inconsistent results were seen when the Cassandra database was queried from the Connect-Cassandra integration connector ruleset. During the queries, data is collected from different systems and loaded into the Cassandra database. If there is a distributed architecture, there is a risk that not all replicas will receive all the insert/updates at the time of the data load for any number of reasons (node down, node overwhelmed, network, etc.).With the default of consistency level 1, the Pega Cassandra query may hit a node that is missing the data requested. However, consistency level 2 forces Cassandra to read matching data from two nodes and in the background will perform a read repair on the node that is missing data. In order to enable the setting of a preferred consistency level for all connectors and for all operations, a new single DSS setting has been introduced: RS: Pega-BigData purpose:connector/Cassandra/consistency available values: " ALL ANY EACH_QUORUM LOCAL_ONE LOCAL_QUORUM LOCAL_SERIAL ONE QUORUM SERIAL THREE TWO"