INC-163723 · Issue 633441
Queue Processors made more robust
Resolved in Pega Version 8.6
After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.
INC-164581 · Issue 634154
Import UI option updated to handle data import for upgrades
Resolved in Pega Version 8.6
After upgrade from Pega 8.1 to 8.5, importing data into the datasets using the Actions->Import UI option was not working. This was due to the previous save operation used in import being deprecated, and has been resolved by instituting a new save operation in import to handle this scenario.
INC-166354 · Issue 637300
Queue Processors made more robust
Resolved in Pega Version 8.6
After upgrade, multiple queue processors were not running as expected. Attempting to restart them generated an error. Investigation showed that the real time data flow runs were not picking up or accepting assignments because the local node was under the impression it was still processing data. In this case, the need to synchronize the state of multiple threads caused the queue processors to become stuck in an initializing state due to a race condition that caused the data flow engine to think this run still had threads running when all threads were already stopped. To resolve this, the callback handling has been simplified and made more robust. In addition, in some cases the data flow leader node would believe the service nodes did not accept assignments even when they did. This occurred if many runs and nodes were involved, and was traced to an implicit limit on the NativeSQL query used to read the data to see which assignments were accepted. To resolve this, the key-value store in the Service Registry has been modified to allow a query of more than 500 entries at once.
SR-69015 · Issue 619995
Unescaping characters implemented for expressions
Resolved in Pega Version 8.3.6, Resolved in Pega Version 8.4.4, Resolved in Pega Version 8.5.3, Resolved in Pega Version 8.6
An issue where expression builder statements were evaluated differently at runtime than at testing has been resolved. Pega Platform expressions with String literals(that is, sequences of characters enclosed in quotation marks) now unescape characters in strategy shapes such as Set Property or Filter.
INC-181148 · Issue 663164
Documentation updated for altering data type to Timestamp to avoid duplicate data in Decision Hub
Resolved in Pega Version 8.5.6
By default, the pxOutComeTime column has a Date data type in the pr_data_ih_fact table. This may cause duplicate data issues. To resolve this, the 8.5 and 8.6 installation and upgrade guides for Pega Customer Decision Hub have been updated to include a new procedure "Modifying column definitions to use the TIMESTAMP datatype in an Oracle database". Performing this procedure will allow users to avoid the duplicate data issue. All documents are available from the Pega Customer Decision Hub product page.
INC-172785 · Issue 662335
Adaptive model retry mechanism enabled
Resolved in Pega Version 8.5.6
Adaptive models were missing from the Model Management page as well as in the Prediction studio while similar models for the same proposition, only differing by the Channel name, were visible. This was traced to data not being synchronized between the database and Cassandra. The pegadata.pr_data_adm_factory database table did not contain the record of the missing channel, but Cassandra did. Since the current Cassandra adm_scoringmodel contained model information, the system still believed the model was present. In order to ensure Cassandra and the database table are in sync, an update has been made to enable the retry mechanism "SyncFactoryKeysTask" to create the ADM model in factory table by periodically looking for scoring models without factories or an entry in adm_meta.
INC-173596 · Issue 660221
Google OAuth and Spring versions updated
Resolved in Pega Version 8.5.6
The Google-oauth-client jar has been upgraded to version 1.31.1, and SpringFramework libraries have been updated to version 5.3.9 .
INC-174661 · Issue 678821
Handling added for clearing node killed between assignment and processing
Resolved in Pega Version 8.5.6
An Offer flow was not resuming after it expired according to the wait shape. Investigation traced this to partitions which were assigned to a dead node in NEW state where they were not picked up by the dataflow. The problem was only encountered in the unusual situation when a dataflow node was killed in the brief period of time between the assignment and the processing, and has been resolved by adding an update which will clear unknown new assigned partitions for the batch run health task.
INC-174781 · Issue 655120
Kerberos authentication added for external Cassandra
Resolved in Pega Version 8.5.6
Support has been added for Kerberos authentication with Cassandra.
INC-175207 · Issue 655553
Added handling for DSM Services stuck in leaving status after database outage
Resolved in Pega Version 8.5.6
During a database outage, the heartbeat would fail and DSM services would eventually try to enter safe mode and stop. As the first step they would try to change the state to LEAVING, but because the database was down saving the LEAVING state failed and the exception was not handled correctly. This resulted in the rest of the stop operation logic not being executed and the service being stuck in LEAVING. To resolve this, an update has been made to ensure the service goes to LEAVING_FAILED if anything fails during the stop operation including when setting state to LEAVING_FAILED. The state LEAVING_FAILED will get flushed to the database eventually when it comes back up. This will allow the aggregation service to start from the LEAVING_FAILED state and recover by itself after a database outage.