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 update your bookmarks. This site will be discontinued in Dec 2024.

Pega Platform Resolved Issues for 8.1 and newer are now available on the Support Center.

SR-A92264 · Issue 268673

Handling added for Connection Closed exception in Rule Search index

Resolved in Pega Version 7.2.2

The Search Index process was completing for Work and Data instances but stopped for Rules at around 65,000 records. This error occurred when Pega returned a database Connection back to the JDBC connection pool once the current request processing is complete: Pega checks if auto commit is marked to the appropriate value before returning the connection back to the pool, but an error occurred. The code now handles the Connection Closed Exception and removes the bad connection from the pool when appropriate.

SR-A85931 · Issue 254345

Class loader resource workaround for CyberArk

Resolved in Pega Version 7.2.2

The use of CyberArk (a 3rd party password manager) to secure database connections resulted in an infinite loop while trying to obtain a db connection. The CyberArk client "walks" the call stack and tries to obtain the URL of each class (resource) in the call chain to verify that all jars referenced are "authorized" to obtain the password, and it is not possible to disable this logic. The loop issue happened because the Pega 7 class loaders read the database during the process of generating the URL for a class, causing another db connection to be requested and starting the validation process again. In order to provide a workaround for the lack of customization in CyberArk, the class loaders have been modified to optionally bypass reading the database when a URL is requested for a CLASS resource (all other resource types must still go to the database to check for existence). The new behavior is enabled by setting the Java system property -Dcom.pega.prminiloader.avoiddbforgetresource=true. (The flag must be a Java system property because it has to be read before any database operations are performed.)

SR-A85937 · Issue 254344

Class loader resource workaround for CyberArk

Resolved in Pega Version 7.2.2

The use of CyberArk (a 3rd party password manager) to secure database connections resulted in an infinite loop while trying to obtain a db connection. The CyberArk client "walks" the call stack and tries to obtain the URL of each class (resource) in the call chain to verify that all jars referenced are "authorized" to obtain the password, and it is not possible to disable this logic. The loop issue happened because the Pega 7 class loaders read the database during the process of generating the URL for a class, causing another db connection to be requested and starting the validation process again. In order to provide a workaround for the lack of customization in CyberArk, the class loaders have been modified to optionally bypass reading the database when a URL is requested for a CLASS resource (all other resource types must still go to the database to check for existence). The new behavior is enabled by setting the Java system property -Dcom.pega.prminiloader.avoiddbforgetresource=true. (The flag must be a Java system property because it has to be read before any database operations are performed.)

SR-A89181 · Issue 257344

Connect-Wait made more robust for timeouts and multiple calls

Resolved in Pega Version 7.2.2

To check an asynchronous thread running for a long time, a connect-wait was given multiple checks for the same pool id. On first execution of this connect-wait, it was unexpectedly timing out before hitting the timeout settings in the parameter. For all of the subsequent calls to connect-wait, it was waiting for the asynchronous thread to complete, i.e. exceeding the timeout limit. Normally Connect-Wait is called once and the wait time defaults to the point where data page load finishes. In this particular use case, when connect-wait hit the timeout due to a user-specified value, the system considered it an error state and cleaned up the pool ID from the thread. The subsequent waits were failing due to the mapping for the pool ID being removed when first Connect-Wait call ended with timeout. To support this use, better handling has been added for the user-specified timeout, and the system will not clear the mapping for the pool ID if Connect-Wait ended due to timeout. In cases where another Connect-Wait request does not come, the mapping will be cleared when the thread terminates.

SR-A90493 · Issue 258125

Connect-Wait made more robust for timeouts and multiple calls

Resolved in Pega Version 7.2.2

To check an asynchronous thread running for a long time, a connect-wait was given multiple checks for the same pool id. On first execution of this connect-wait, it was unexpectedly timing out before hitting the timeout settings in the parameter. For all of the subsequent calls to connect-wait, it was waiting for the asynchronous thread to complete, i.e. exceeding the timeout limit. Normally Connect-Wait is called once and the wait time defaults to the point where data page load finishes. In this particular use case, when connect-wait hit the timeout due to a user-specified value, the system considered it an error state and cleaned up the pool ID from the thread. The subsequent waits were failing due to the mapping for the pool ID being removed when first Connect-Wait call ended with timeout. To support this use, better handling has been added for the user-specified timeout, and the system will not clear the mapping for the pool ID if Connect-Wait ended due to timeout. In cases where another Connect-Wait request does not come, the mapping will be cleared when the thread terminates.

SR-A15970 · Issue 249633

Data population clipboard updated to handle mixed copy type

Resolved in Pega Version 7.2.2

Trying to load the auto populate property 'Address' with a data page was not working due to a Ref-Type AP that was present inside a Copy-Type AP. This was found to be a flaw where all the pages in the subtree of the copy type AP have a special java status set, whereas the property elements have the special java status unset, causing the Ref-type AP inside copy-type AP to fail to populate. The data population clipboard functions have been updated to handle this case.

SR-A101848 · Issue 270084

Obj-Browse accepts Embedded Code-Pega-List

Resolved in Pega Version 7.2.2

Trying to reference a Property of Page Code-Pega-List in an activity using Obj-Method activity generated an error when executing, indicating that an invalid page name was passed. However, according to the Obj-Browse method help screen, there is no restriction on whether this page has to be top-level or embedded. After analysis it was determined that the code did not previously allow embedded pages in obj-browse, and this has been added to support this use.

SR-A100617 · Issue 267626

Typos corrected in SQL error

Resolved in Pega Version 7.2.2

Typographical errors have been corrected in the message generated by a pzInsKey SQL error.

SR-A26298 · Issue 249983

Corrected JNDI name mismatch on node quiescence

Resolved in Pega Version 7.2.2

When a JBoss HA environment attempted to quiesce a node where the JNDI name used for PRAdapter Connection factory was different in the RAClient.java and ear properties due to reference shortcuts, a JNDI name not found exception was logged and the node never entered a full quiesced state. To resolve this, the system will now ensure the JNDI name is referenced with full context.

SR-A26298 · Issue 250821

Corrected JNDI name mismatch on node quiescence

Resolved in Pega Version 7.2.2

When a JBoss HA environment attempted to quiesce a node where the JNDI name used for PRAdapter Connection factory was different in the RAClient.java and ear properties due to reference shortcuts, a JNDI name not found exception was logged and the node never entered a full quiesced state. To resolve this, the system will now ensure the JNDI name is referenced with full context.

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