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.

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.

INC-149370 · Issue 619990

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.

INC-150809 · Issue 611855

Loading timing updated for openAPI content

Resolved in Pega Version 8.4.4

Open API content loading was taking too much time and interfering with working on other REST rule configurations. To resolve this, the loading of openAPI contents has been removed from the opening or saving of REST rule and shifted to lazy loading. Clicking on the openAPI tab will load the contents, and any modification in REST rule or service package rule will update the contents of openAPI when "Action->Refresh" is clicked.

SR-D56293 · Issue 536776

Resolved timeout errors related to getIndexInfo

Resolved in Pega Version 8.1.8

When attempting to import large files (around 300MB) via Designer Studio a time out error was seen, but the same upload worked as expected from the command line. Investigation showed that the "approximate" argument in getIndexInfo caused wasteful analytic operations to be run on the database, hampering performance. To resolve this, areas where the results of the analysis are not needed have been modified to have aApproximate set to be true so it will not be run.

INC-215354 · Issue 712666

Data- flow actions working in Bulk Process

Resolved in Pega Version 8.8

When trying to render a flow action whose 'applies to' class was inherited from Data-, an error was generated indicating that the flow action could not be found. This was traced to non Work- flow actions not being correctly populated, and was an inadvertent side effect of work done to set class for inheritance if Work- is not present. This has been resolved by updating the pzPreBulkProcessModal activity to set the TempWorkPage class to Work- only if .pyActionName is pyTransferAssignment.

INC-213610 · Issue 708115

Job Scheduler explicitly unlocked after nodes restart

Resolved in Pega Version 8.8

If a job scheduler was in running state and the utility nodes were restarted, the background processing nodes were not coming up and resuming as expected and PersistentJobCleanupFactory:PresentMembersJobCleanup was throwing a stale execution exception. Investigation showed locks were not being removed from the database for the job scheduler when the restart was performed (noted in pegadata.pr_sys_locks table), preventing further runs. This has been resolved by adding an explicit lock removal process for this condition.

INC-213763 · Issue 708111

Job Scheduler explicitly unlocked after nodes restart

Resolved in Pega Version 8.8

If a job scheduler was in running state and the utility nodes were restarted, the background processing nodes were not coming up and resuming as expected and PersistentJobCleanupFactory:PresentMembersJobCleanup was throwing a stale execution exception. Investigation showed locks were not being removed from the database for the job scheduler when the restart was performed (noted in pegadata.pr_sys_locks table), preventing further runs. This has been resolved by adding an explicit lock removal process for this condition.

INC-229192 · Issue 729614

Job Scheduler explicitly unlocked after nodes restart

Resolved in Pega Version 8.8

If a job scheduler was in running state and the utility nodes were restarted, the background processing nodes were not coming up and resuming as expected and PersistentJobCleanupFactory:PresentMembersJobCleanup was throwing a stale execution exception. Investigation showed locks were not being removed from the database for the job scheduler when the restart was performed (noted in pegadata.pr_sys_locks table), preventing further runs. This has been resolved by adding an explicit lock removal process for this condition.

INC-218265 · Issue 720611

DoClose updated to resolve lock and context issues

Resolved in Pega Version 8.8

An interaction case was closing when intent tasks were closed from CSRecents. Investigation showed this was due to the doClose activity not being triggered in the right context, and has been resolved. An additional issue with locks not being correctly released after opening the new case Create stage and clicking Cancel in the modal was traced to a missing pyWorkPage in the safeURL params that was needed by the doClose activity, and this has been resolved by adding the primary page name.

SR-D68558 · Issue 536676

Timing updated for Cassandra session change thread lock

Resolved in Pega Version 8.1.8

An issue with unresponsive nodes was traced to the method used for notifications about Cassandra session changes. A thread trying to obtain a Cassandra session acquired a read lock, then if it then determined that a new session had to be created it would also acquire a write lock, preventing other nodes from trying to acquire the session. After creating a session, the thread notified all session change listeners while holding the write lock, causing deadlock with dependent services. To resolve this, the timing has been updated by moving the session change notification to the listeners outside of the section guarded by the lock.

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