SR-C69567 · Issue 409190
ICMP ping flag enabled and Hazelcast alerts/info messages added
Resolved in Pega Version 8.1.3
Hazelcast Professional Services recommends enabling ICMP ping as a method to detect network failures more quickly. This can also help to determine whether a failure is due to a network outage: if the ICMP ping is successful but the heartbeat timed out, that may be an indication of a unresponsive (GC pause, long running process, etc) node. To facilitate this use, the ICMP ping flag can now be used in conjunction with enabling ICMP ping on EC2 through the security group and enabling ICMP in the Hazelcast configuration.In order to facilitate determining root causes for Hazelcast errors in the logs, the following alerts and info messages have been added: Actionable Events (Alerts): Each of these events is worth noting an alert for. An action may be necessary. - [Partition] Lost - A partition was lost. Possible data loss has occurred - [Lifecycle] Merge Failed - A member’s attempt to merge with the cluster has failed - [Migration] Migration Failed - A partition migration has failed Non-Actionable Events (Info): These events are of interest but don’t require any actions. - [Membership] Added - A new member was added to the cluster - [Membership] Removed - An existing member has left the cluster - [Lifecycle] Merging - A member is merging with the cluster - [Migration] Started - A partition migration has started - [Migration] Completed - A partition migration has completed - [Lifecycle] Shutting Down - A member is shutting down
INC-148853 · Issue 609318
Corrected password comparison handling for CopyMerge Ruleset Wizard
Resolved in Pega Version 8.4.4
When running the CopyMerge Ruleset Wizard, entering the password failed with the error "pyPassword: Invalid Password for" <Temp:01-01-01> for each ruleset. Investigation showed that the system was calling an activity which encrypted the user input, causing the comparison with the stored password of the system to fail the match. This has been resolved by removing the extra encryption so the call to the comparison evaluates correctly.
INC-183947 · Issue 673733
Query split added to handle Oracle expressions limit
Resolved in Pega Version 8.7
The PXCHECKFLOWDEPENDENCIES activity was throwing the Oracle error message "ORA-01795: maximum number of expressions in a list is 1000" when a case had a very large number of sub-cases, causing a failure in trying to submit additional child cases which sent them into the broken process. This has been resolved by updating the pxCheckFlowDependencies rule to break down the query parameter into batches of 999 so they can be handled by Oracle.
INC-184155 · Issue 673072
Entity Detection prefers first detected entity
Resolved in Pega Version 8.7
Entity detection shown in the "Training data" tab of the email channel did not match with the results of running the corresponding text analyzer rule. This occurred when a single piece of text was detected as multiple entity values, which led to the last entity detected being picked for case mapping because of the unclear scenario of duplicate entities. To resolve this, pxmapresponseentities has been updated to prefer the first detected entity.
INC-184834 · Issue 669458
Channel copy text analyzer detection updated
Resolved in Pega Version 8.7
The error message "No unlocked Ruleset versions are available. Please add or unlock a ruleset to create a new channel." was displayed when trying to save a new interface. This was traced to the system copying the channel to incorrect classes/names due to detecting an incorrect type of text analyzer and copying the wrong rules. To resolve this, the method of detecting the text analyzer type on channel copy has been updated.
INC-176173 · Issue 654726
Re-indexing correctly triggers old index deletion
Resolved in Pega Version 8.7
There was no request to delete the old index when a new reindexing process was started, resulting in the new data being put into the already existing index. This was traced to a logic flaw which evaluated a condition as false under certain conditions. This 'If' condition has been fixed and simplified so the process responsible for recreating the ElasticSearch index is accessible for the scenario of reindexing an entire index without specifying include or exclude classes.
INC-178663 · Issue 659805
Updated handling for batch indexing cancellation
Resolved in Pega Version 8.7
Entries were seen in the pyBatchindex QP even when indexing was not in progress. Investigation showed that if an exception occurred during the cancel process, the pyStatusWork property in Log-Cluster-FTSIndex instance was not correctly updated and the value remained as CancelInProgress. As a result, SLP silently remained in the state of waiting for the completion of cancel operation. This has been resolved by updating the handling of the cancellation process to ensure the queue is correctly cleared and email notifications are sent as expected.
INC-186782 · Issue 674952
Re-indexing correctly triggers old index deletion
Resolved in Pega Version 8.7
There was no request to delete the old index when a new reindexing process was started, resulting in the new data being put into the already existing index. This was traced to a logic flaw which evaluated a condition as false under certain conditions. This 'If' condition has been fixed and simplified so the process responsible for recreating the ElasticSearch index is accessible for the scenario of reindexing an entire index without specifying include or exclude classes.
INC-143908 · Issue 606551
Data Page Save correct in batch mode
Resolved in Pega Version 8.4.4
After configuring a List type savable Data Page with save activity in Code-Pega-List, the save data page was triggered from utility of flow from the queue processor to handle queueing 10k data items and creating 10k work objects. When this was run, a field dpClassName was being changed by different threads in DataPageSaverImpl.java. This has been resolved by making the class DataPageSaverImpl.java stateless to ensure thread safety.
INC-145756 · Issue 619293
Logging for MultiNodeSynchronize lock attempts changed from error to warn
Resolved in Pega Version 8.4.4
The File Listener was logging numerous errors stating "Unable to establish MultiNodeSynchronize lock while trying to determine if listener is enabled for this node". Handling has been previously established for error cases when the Listener is unable to establish a MultiNodeSynchronize lock, but this condition continued to be logged as an error even though it was not related to any failures in functionality. To resolve the logging issue, the logger level has been changed from ERROR to WARN.