INC-133202 · Issue 574700
TableRenameUtil hashing improved
Resolved in Pega Version 8.2.8
During index name generation, the algorithm that was responsible for index name uniqueness was sometimes insufficient and cerated a loop condition. This has been resolved by using a stronger hash algorithm and refactoring the code that could result in a loop.
INC-174567 · Issue 651121
Permissions added to handle Openshift installer image
Resolved in Pega Version 8.7
When running the install process on an Openshift test cluster, the process failed with a permissions error while attempting to download the postgresql-42.2.12.jar. This has been resolved by ensuring the root group can write to the distribution files.
INC-175197 · Issue 651114
Permissions added to handle Openshift installer image
Resolved in Pega Version 8.7
When running the install process on an Openshift test cluster, the process failed with a permissions error while attempting to download the postgresql-42.2.12.jar. This has been resolved by ensuring the root group can write to the distribution files.
INC-132218 · Issue 573358
Resolved buffer overflow for Migration loadDatabase
Resolved in Pega Version 8.2.8
A Rules upgrade failed in the Migration step at loadDatabase stage, involving the move of all the table records from old schema to new schema. This was traced to the inability of Migration to load blob of sizes more than 100 MB, and has been resolved by updating Migration to use byte[] to read the blob content with the help of metadata that contains blob length.
INC-173663 · Issue 651302
Resolved Push Node Daily Information exception
Resolved in Pega Version 8.7
The "Push Nodes Info Daily" agent was generating an exception on each of the nodes. This has been resolved by enhancing the PegaAESRemote code to handle the exception and get the node info locally, then push it to the console when it is not able to get it via the cluster management API.
INC-175205 · Issue 652531
Agent restart made more resilient
Resolved in Pega Version 8.7
During a timeout outage, agents intermittently encountered a NoClassDefFound error and were disabled. After the database connection was restored, the agents were not automatically restarting. This has been resolved by making the code more resilient to errors; agent will be restarted when a temporary issue is detected, and the restart will be immune to most exceptions.
INC-189781 · Issue 677816
Database Transaction Log update overflow resolved
Resolved in Pega Version 8.7
When automatic.resume=false was encountered during an update, cleaning up the existing codeset from previous updates ended up filling up the database transaction logs and caused the update to fail. This has been resolved by updating the process of clearing the codeset so it doesn't overflow the transaction log.
INC-178002 · Issue 663770
Restore point handling updated for absent pzpvstream column
Resolved in Pega Version 8.7
While executing the “get restore point” action for rollback, a PZPVSTREAMerror error occurred with the message "(util.HistoryCollectorDataModel) WARN|Rest|SystemManagement|v2|restorepoint - History collection for the table will be slow because it does not have all of the required columns". This was a missed use case for Robotics Automation not having a pzpvstream column for one of the tables; this has been corrected with a check to validate for pzpvstream column so the system will not seek history records if the pzpvstream column is not present.
INC-177512 · Issue 657015
Hazelcast packages expanded for Java9+ with kubernetes
Resolved in Pega Version 8.7
Hazelcast warnings were seen in cluster logs when Hazelcast was run in embedded mode or c/s mode on a java modular environment i.e. java 9+ which noted that performance and functional impact issues may result if certain internal modules of java are not given reflection access. This update provides the necessary access to some additional java internal modules/packages per the Hazelcast recommendation.
INC-190070 · Issue 676643
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.