INC-141570 · Issue 597845
Performance improvement for first JVM with Oracle
Resolved in Pega Version 8.5.1
After performing a fresh installation of Pega with Oracle DB, the first JVM was taking an excessive amount of time to come up, and logins were also very slow. This was caused by code that optimized node startup query performance by shipping completed assemblies for Oracle that are not recommended for use with newer Oracle versions (10 or newer). This has been resolved.
INC-122072 · Issue 581029
Delay in writing database template records resolved
Resolved in Pega Version 8.5.1
After upgrade. a real-time event based campaign with an offer flow that used a database template showed an excessive delay in updating the database template. A queue entry related to "WriteOutboundAgent" was also showing as failed, and analysis of the logs showed that the transaction type was not being set. This was traced an exception during a regular close operation of the result set iterator: the API used to close the transaction contained code specific to PostgreSQL while the site was using Oracle. This has now been resolved.
INC-140750 · Issue 589925
Resolved post-passivation login issue
Resolved in Pega Version 8.5.1
An authentication error was seen when operators tried to log in again after passivation. This was traced to a corrupted BLOB, and has been resolved.
INC-121147 · Issue 580394
ContextMap cache handling updated to address reverse map corruption
Resolved in Pega Version 8.5.1
An issue was seen with intermittent login failures. A network trace revealed indefinite 303 redirects happening during the attempted connection. If the access group was resaved under a new name, the login worked. This was traced to a thread issue in Java’s implementation of PBEKeySpec that caused the reverse ContextMap cache to become corrupted. To resolve this, the system has been updated to compare the access group from the reverse map and the access group passed for encryption (which will always be correct) and correct the map if necessary.
INC-139611 · Issue 587599
Timezone.getDefault function replaced for performance improvement
Resolved in Pega Version 8.5.1
Blocking threads were seen around the GregorianCalendarFactory.clearObject(Object) function, leading to an adverse impact on the performance. TimeZone.getDefault() is a synchronized method call, and under high load this method caused contention when more date-related APIs were invoked. To resolve this, Timezone.getDefault() has been removed and the function has been assigned to a static variable used in the clearObject() API.
INC-131666 · Issue 581066
Oracle date handling issue resolved
Resolved in Pega Version 8.5.1
For the specific date time 1900-01-01 00:00:00.00, the UI showed the date as 31/12/1899 10:55 PM. This has been resolved by inserting a fix from Oracle that addresses an issue with dates in the early 1900s.
INC-135823 · Issue 580925
Transient property passivation handling improved
Resolved in Pega Version 8.5.1
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-130055 · Issue 578633
Page Validation logging updated
Resolved in Pega Version 8.5.1
In order to enhance troubleshooting, additional logging has been added to capture information for Page Validation failures.
INC-138649 · Issue 585356
Timezone retrieval performance enhancement
Resolved in Pega Version 8.5.1
In order to improve performance and reduce a potential bottleneck for concurrent threads, PRDateTimeUtilsImpl has been updated to use a common GMT timezone object rather than getting the timezone for each operation for each function call.
SR-D97738 · Issue 580162
Class Loader cache values wrapped with WeakReference for improved cleanup
Resolved in Pega Version 8.5.1
Out Of Memory exceptions due to Metaspace were observed on Web tier instances running with a max Metaspace size of 2GB. Investigation showed that in PRClassLoaderDB, mLoaderCache values were wrapped with a SoftReference. To resolve this, the Class Loader cache values will be wrapped with a WeakReference, allowing the cache to free memory when it is no longer needed. JVM options has also been added to switch types of References being used if there is a preference.