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.

INC-135823 · Issue 580944

Transient property passivation handling improved

Resolved in Pega Version 8.2.8

Frequent "com.pega.pegarules.pub.PRRuntimeException" errors were seen in the production log file while working on the WO. This was traced to corruption in the blob caused by transient properties during passivation. To resolve this, corrections have been made to the handling for the transient property entries in the blob.

INC-138840 · Issue 599979

Data-Summary reports default will not use the rule resolved setting

Resolved in Pega Version 8.2.8

An intermittent issue was seen where a query could become stuck for ~2 hours in the database. This has been resolved by setting the default for Data-Summary reports to not use the rule resolved setting.

INC-127976 · Issue 566157

Delete Requestor method updated for use with CMT

Resolved in Pega Version 8.2.8

JMS MDB Listeners with Container Managed Transaction (CMT) enabled in Websphere 8.5 had global transactions fail. To initialize a JMS-MDB listener, a requestor of type APP is used. Upon the service being fully initialized, the requestor is removed by executing a delete operation followed by a COMMIT. However, in this scenario, the initialization operation is running within a CMT context and a SQLException was raised indicating that the commit was not allowed. To resolve this, the delete requestor method has been refactored to take into account the CMT context so the commit is not executed if the transaction is managed by the container.

INC-121359 · Issue 571026

Resolved sync error for offline workorder

Resolved in Pega Version 8.2.8

After logging on to the mobile app and then switching to off-line mode before opening a workorder from the worklist and processing the full workorder from end to end in offline mode, reconnecting resulted in the work order being moved to the [email protected] work basket with “Sync-Failed” status. Investigation showed that this was a caused by the DateTime properties being an empty string or null despite being created with a valid string. This was traced to the datetime conversion handling, and has been resolved.

INC-127229 · Issue 568096

HTTPClient updated to match Apache's ConnectionRequestTimeout changes

Resolved in Pega Version 8.2.8

Connect Rest services were not timing out at the expected 60 second mark, but were instead running for 120 or even 200 seconds. This bug arose as a result of Apache's refactoring of their HTTPClient in version 4.3. This refactoring split ConnectionTimeout into two variables, ConnectionTimeout and ConnectionRequestTimeout, in order to give users more granular control over client timeout behavior. The implementations of HTTPClient have now been amended so that all HTTP Client configurations set ConnectionRequestTimeout appropriately.

INC-128800 · Issue 582622

HTTPClient updated to match Apache's ConnectionRequestTimeout changes

Resolved in Pega Version 8.2.8

Connect Rest services were not timing out at the expected 60 second mark, but were instead running for 120 or even 200 seconds. This bug arose as a result of Apache's refactoring of their HTTPClient in version 4.3. This refactoring split ConnectionTimeout into two variables, ConnectionTimeout and ConnectionRequestTimeout, in order to give users more granular control over client timeout behavior. The implementations of HTTPClient have now been amended so that all HTTP Client configurations set ConnectionRequestTimeout appropriately.

INC-128800 · Issue 592820

Additional DSS added to handle Apache client-level timeout

Resolved in Pega Version 8.2.8

n Connector rule, the system timed out a connection after 1 hour even after a connection time timeout was configured to be 30 seconds. Apache's refactoring of their HTTPClient in version 4.3 specifies request timeouts in two ways: on the client-level and on the request-level. Client-level timeouts are enforced prior to and during the handshake, whereas request-level timeouts are enforced after the handshake has been made. Previously, RESTConnector.java and ComponentsHTTPClient.java were configured to only set the user-specified timeout on the request, and not on the client. This caused the client-level timeout to default to "0", or an infinite amount of time. In this reported issue, the remote host closed the connection before the handshake had been completed so the connection remained open for several hours. To resolve this, the DSS "ClientLevelHTTPTimeout" has been added to allow specifying a client-level socket timeout, and ComponentsHTTPClient.java and RESTConnector.java have been amended to assign this value to the client. This DSS is set to 0 by default to preserve backwards compatibility.

SR-D88499 · Issue 551186

Check added to minimize Obj-Open-By-Handle error logging

Resolved in Pega Version 8.2.8

When using a Data Type with the "Automatically generate a unique id " option, calling the Save-DataPage method by using the savable data page of the data type finished correctly but showed Obj-Open-By-Handle errors on PegaRules.log. Investigation showed the exception was thrown when running the save plan from DataPageSaverImpl: while attempting to run the save plan, the system does not know whether a parameter (pyGUID in this case) will be required to run the save plan or not, meaning that it can't detect any possible error in DataPageSaverImpl. The implementation instead makes a call to db.open to check if an instance exists and hence logs are thrown. To resolve the error logging, a check has been added: if the save-to class has an autogen key and the savable data page instance doesn't have the autogen key in it, the system will directly call pxCreateRecord. This will avoid a call to db.open to check if instance exists and hence no failed logs will be thrown. This partial change will work only for classes having an autogen key and in cases where the page is trying to create a record by intentionally not passing the key.

INC-127635 · Issue 570056

Handling added for BIX count mismatch in manifest and extracted CSV data

Resolved in Pega Version 8.2.8

A mismatch in the counts in the manifest file when compared to the data extracted in the CSV files was traced to a corrupted or wrong pzinskey in the source database. If the BLOB is corrupted while extracting to output type and manifest type to CSV, an invalidstream exception was generated and resulted in the manifest file and extracted CSV file total instance count mismatch. This has been resolved by adding handling to balance the counts.

INC-120326 · Issue 567449

Landing page refresh modified to avoid frequent reloads

Resolved in Pega Version 8.2.8

Approximately every two weeks, clients were able to login but it was not possible to work as the landing page refreshed constantly until all of the nodes were rebooted and the issue was cleared. Investigation indicated the frequent reloads were related to the cacheing of the operator details, and this has been resolved by updating the datapage reload strategy based on 'when' so frequent reloads will be avoided.

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