Skip to main content

Resolved Issues

View the resolved issues for a specific Platform release.

Go to download resolved issues by patch release.

Browse release notes for a selected Pega Version.

NOTE: Enter just the Case ID number (SR or INC) in order to find the associated Support Request.

Please note: beginning with the Pega Platform 8.7.4 Patch, the Resolved Issues have moved to the Support Center.

SR-D51722 · Issue 515359

ClusterAndDBCleaner agent will remove extracts older than 30 days from pr_log table

Resolved in Pega Version 8.4

In order to better manage pr_log table size and query performance, an enhancement has been added to control the purge of entries of extract type. The default is to delete entries older than 30 days.

SR-D55106 · Issue 525464

Improvements to error recovery and logging for BIX extracts

Resolved in Pega Version 8.4

Previously, the BIX incremental extraction would restart from the last extraction date time if it had a failure, even if some batches were processed successfully, and the starting and ending datetime considered for the incremental extraction were not logged. As part of this update, extractions will resume from the point of failure instead of starting all over again, and the logging has been enhanced to include Information about the parameters used for extraction (starting time, end time, #of records processed/failed etc). However, if the -f flag is set, batch level failures will cause BIX to terminate but blob read errors will not. This causes the restart logic in this fix to not function properly in the face of blob read errors such as an ORA-01555 when reading the blob. Resolution for that aspect of this issue will be provided in a future release.

SR-D55161 · Issue 527652

getStoreDataTable updated to resolve thread lock issues

Resolved in Pega Version 8.4

An IlegalMonitorStateException in TableInformationMapImpl.getDataStoreTableInfo caused a read lock to not be released, preventing other threads from acquiring a ReentrantReadWriteLock.WriteLock on the same ReentrantReadWriteLock. This eventually lead to a Deadlock scenario forcing other threads into an irrecoverable WAITING state. The issue could be cleared by restarting the nodes, but the implementation of the getDataStoreTableInfo method has been updated to resolve this issue.

SR-D64220 · Issue 535133

Reinitializing Full Text Search will shut down Elastic Search regardless of search initialization status

Resolved in Pega Version 8.4

Pega search was only sporadically working after converting from standard sandbox-marketing to largesandbox-marketing. This was traced to the Full-Text Search initialization having failed on the app-tier node during re-initialization. As part of re-initialization, the existing node is shut down and the Elastic Search node is started. The shutdown process relied on a boolean flag which indicated if the current status of full-text search initialization was successful. In this case, ES was trying to validate all the cluster level settings, for every save of one of the cluster level settings, but could not due to topology changes in the Util Tier node. The boolean flag indicated initialization had failed so the shutdown process was not invoked, yet the system was attempting to start the second instance of an ES node on the same machine. To resolve this, the shutdown FTS code has been modified to shutdown ES regardless of the search initialization status.

SR-D65944 · Issue 533395

Parent case lock properly released when child case is resolved

Resolved in Pega Version 8.4

After creating Parent-Child casetypes with default locking where the child case had the “Allow access to parent” check box checked, the temporary lock acquired on the parent during resolution of the child case was not released afterwards. If “Allow access to parent” was not checked, then the locks were released on both the parent and the child. This was traced to a combination of parameters used by the openIfStale() API where aUnlockOnCommit could be set to false despite the provided locking strategy expecting it to be true, as well as honoring UnlockOnCommit when maintainLockingStrategy is false. To resolve this, the system has been updated to always check whether the lock is available in the map already and if it is, then set unlockonCommit to true. Otherwise, under all cases, honor the passed-in unlockOnCommit value.

SR-D16427 · Issue 495818

Multi-nodes rebuild LibraryMetadata to ensure all Rule-Utility-Functions are present on change

Resolved in Pega Version 8.4

When performing a complete Application import into a clean installation, references to certain Rule-Utility-Functions went unresolved during the initial assembly. Investigation showed that after introducing a new Rule-Utility-Library or Rule-Utility-Function on one node in a cluster and then generating that, the other nodes in the cluster did not have the correct LibraryMetaDataCache for that Rule-Utility-Library.Therefore assemblies on those other nodes could be bad and throw a runtime UnresolvedAssemblyError. This has been resolved by modifying the way the Library subsystem processes the node changes events for Library Generation to ensure that each node completely rebuilds the LibraryMetadata for that Rule-Utility-Library so it contains all the Rule-Utility-Functions.

SR-D18120 · Issue 496424

JMS push notification made more robust

Resolved in Pega Version 8.4

After creating a JMS Service to call pySendPushNotification from an activity, running it using User Context worked as expected but selecting initialize Service Context resulted in the Push notification silently failing in the context of JMS service. The JMS is used as a communication medium between legacy and Pega solutions. When the message arrives, Pega creates a new case and sends a push notification to the user, who has only 2 minutes to accept the case. Because of the urgency of timeliness in this situation, the push is sent directly from the context of the service rather than expend 30 seconds for agent processing. However, because the application was not always available to the pySendPushNotification activity (and further to API call), the push failed. In order to avoid this condition, the system has been modified to use the more widely available pxThread instead of Application when possible.

SR-D24187 · Issue 506128

Catch block added to handle invalid FindAndUpdateElement clipboard data

Resolved in Pega Version 8.4

An exception was generated relating to "Unable to passivate page on thread '<savedwork>' . The following items were not serializable: [Property not serializable: "Declare_pyDisplay.pyDisplay(InteractionPortal).pyUIElements(3).pyParameters.activityParamPage" Class: "com.pega.pegarules.pub.runtime.ParameterPage." This was traced to invalid data in the clipboard, and has been resolved with the addition of a catch block in pzFindAndUpdateElement Rule-Utility-Function which will put an empty string in the clipboard whenever there is an invalid value in the 'Declare_pyDisplay.pyDisplay().pyUIElements().pyParameters' clipboard page.

SR-D24261 · Issue 492559

Updated retry for context registraton

Resolved in Pega Version 8.4

The system was intermittently hanging after importing zipped files. Investigation showed that Batch threads were becoming stuck in AuthorizationContextManagerImpl.setSpecializations() due to a 'while' loop in setSpecializations that was seeking to register the new context. To resolve this, logic has been added which will try to register up to 10 times. If for any reason it can't register, the system will just return the unregister LAC. The check before deregister has also been enhanced and now will only deregister if the new context and the current context are different. It will not call register if the current context and the new context are the same.

SR-D25163 · Issue 504612

Improved query efficiency for bulk processing

Resolved in Pega Version 8.4

Spikes were observed in Library Cache usage. These were traced to queries that originated from Agent 'AgentBulkProcessing' and the activity 'PzAgentBulProcessing' that used "like" and "as", which were not performance efficient in a large-scale installation. The queries in the CheckBulkProcessQueue activity have now been updated to improve performance.

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us