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-C37763 · Issue 377796

UNIX JAR paths documentation correction

Resolved in Pega Version 8.1

The documentation for prconfig/compiler/defaultPaths has been corrected as follows: "For UNIX systems, separate the JAR files with a colon."

SR-C37810 · Issue 381739

Agent management made more resilient against DB connection errors

Resolved in Pega Version 8.1

Intermittently after a database interruption occurred, agents would end up in a state where they did not run. When viewed via SMA they appeared to be running, but the next runtime was blank and the agent did not execute. Attempts to stop/restart an affected agent yielded an error, but restarting the system put the agents back into a operable state. This was a corner case caused by a DB connectivity issue where agents were first being stopped and then attempts to instantiate AgentNotification() also failed due to the DB connectivity issue. To resolve this, AgentNotification will be instantiated during AgentQueue creation itself so it will remain available. All exceptions /errors in AgentNotification will be logged.

SR-C38054 · Issue 380396

Improved validation and handling for Cassandra data set flows

Resolved in Pega Version 8.1

When using a Data flow which read from a file and wrote to a Cassandra data set, the successful records were not written to the Data set if there were any errors. In addition, when all records failed the run stat's '# Failed records' displayed the number of batches, not the actual number of records. This was caused by a condition where if serialization fails it throws a single exception for the whole batch instead of a batch exception, and by default there was a maximum of 250 records per batch. This has been corrected by setting the system to keep the failure threshold to 100,000 and validate that all the failed number of records is correct, then re-process the failed records and check if the dataflow still shows all the failure records.

SR-C38059 · Issue 376811

Improved logging and resilience with S3 bucket configurations

Resolved in Pega Version 8.1

The S3 bucket configuration through DSS did not handle error conditions well, leading to a situation where the engine would not start if the S3 bucket is not configured correctly (e.g., permission setup on the AWS side). The code has now been updated to add better logging around running a repository with DSS System, and startup is no longer stopped if a repository fails to register.

SR-C38060 · Issue 385590

Timing resolved so pxDateTime control accepts Pega Date Time value on the first input

Resolved in Pega Version 8.1

In Pega Mobile android client, pxDateTime that was displayed within a dateTime field using a calendar selector was throwing an error on the first encounter if the field value was already filled using the Pega DateTime format of "yyyymmddThhmmss.SSS zzz". The console error from the templating engine was: "The specified value "20180605T103556.398 CDT" does not conform to the required format. The format is "yyyy-MM-ddThh:mm" followed by optional ":ss" or ":ss.SSS". " This was traced to the handleNativeDate function in pzpega_control_datePicker.js file executing "pega.u.d.CalendarUtil.fireClientEvents(hiddenInput);" two times. Before firing the first event "onchangehandler" returned null, so the 'if' condition executed to true and fireClientEvents was again getting executed. Because there was no delay in between these executions, the second event was getting executed while the first event was still in progress, causing the DOM value of the property to not be properly set before validation was getting triggered during the second invocation. This has been resolved.

SR-C38087 · Issue 386087

Join order fixed to improve Cache SQL Statement performance

Resolved in Pega Version 8.1

The Pega Cache SQL Statement was taking much longer than normal to run when SQLServer 2012 was used. DBA Analysis of the issue showed that Full INDEX Scans were occurring, doubling/tripling the amount of time to respond to the PRPC instance. This was caused by an incorrect join order, and has been fixed.

SR-C38293 · Issue 379308

Added explicit cleanup of non-serializable objects in the Connect-SOAP ParameterPage

Resolved in Pega Version 8.1

In investigating an application continuously logging error messages for Serialization, it was found that Connect-SOAP execution leaves non-serializable objects in the ParameterPage, which in-turn caused this the error logging upon requestor passivation. To resolve this, code has been added to remove the pyServiceClient, soapHdr, and activityParamPage parameters from the ParameterPage after use.

SR-C38299 · Issue 377521

Handling added for data flow thread hang

Resolved in Pega Version 8.1

If there were errors on some partitions, the data flow was hanging. Handling has now been added for system failures in inputSource so the flow will complete and report errors.

SR-C38355 · Issue 376510

"403 - Forbidden" error replaced with "404 - Not Found" for better security

Resolved in Pega Version 8.1

Previously, invalid path information sent for a static content request resulted in a "403 - Forbidden" response that revealed the existence of the directory, even though access is not allowed. For better security, a "404 - Not Found" response status code will be issued for a forbidden resource.

SR-C38450 · Issue 379292

StartupDelay parameter added to allow spacing threads to improve database performance

Resolved in Pega Version 8.1

When starting a data flow with DBDataSet as source shape, all data flow nodes (threads) started hitting the Database at the same time, overloading the system and causing delays for other requests. To resolve this, a new RunOption has been added; pyStartupDelay will add a delay between each thread starting. For example, when setting the delay to 2 seconds, thread 1 will start immediately, thread 2 will start after 2 seconds, thread 3 after 4 seconds etc. In this fashion only one thread at the time will start hitting the DB in a distributed 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