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.