INC-219186 · Issue 720470
Prefix allowed for aggregates Keyspace
Resolved in Pega Version 8.6.5
Attempting to connect multiple Pega environments to an external Cassandra cluster with limited database access using the prconfig setting dnode/keyspaces_prefix resulted in the error "Unable to determine if cassandra table [aggregates.config] exists" while connecting to the aggregates Keyspace. This was traced to an incomplete implementation: the system allowed the keyspace to be created with the prefix, but queries used the keyspace name without the prefix. In order to support this use, an update has been made to ensure keyspace prefixes are used if present.
INC-220174 · Issue 716384
Improved cleanup for data from joining nodes
Resolved in Pega Version 8.6.5
A Cassandra node that is down for longer than the grace period (default 10 days) can introduce zombie data that creates instability when it returns to the cluster. This can include VBD partition summary data that was deleted and can break loading rules and cause the service to fail to start up. To resolve this, additional logic has been implemented to detect zombie summary records, including summary records without field descriptors and summary records without dictionaries having already been provided, and to read dictionaries from the latest summary record in case there are preceding zombie records with dictionaries.
INC-222561 · Issue 721043
Check added for destination type for distribution test reports
Resolved in Pega Version 8.6.5
When there were two output destinations in the system, one of type VBD and another of type Database table and both had the same name, an incorrect class was set for distribution test reports and an error was generated when trying to open the report. Investigation showed the system was only checking for the name of the destination and not its type; this has been resolved by adding a pzSetSimulationOutputClass data transform to check for the destination type in addition to the destination name when setting the class for reports.
INC-224038 · Issue 723258
Performance improvement for serviceregistry table queries
Resolved in Pega Version 8.6.5
The expression filter ($1 - "SSR"."pytimeout") in the queries for service registry table caused full table scans which might result in performance issue and even risk of contention/locking. This has been resolved by replacing the pyTimeout column reference in filters to the default value = 9000ms so that performance for these queries can be improved.