SR-D79178 · Issue 543312
SameSite cookie setting added for Mashup support in Google Chrome v80+
Resolved in Pega Version 8.2.6
The Google Chrome browser version 80 and above now treats SameSite with a blank value as "Lax" by default, causing mashup scenarios to break. In order to compensate for this change, support has been added for setting SameSite=None in Cookie Settings in the CSRF LP (DevStudio-> System-> Setting-> CrossSiteRequestForgery) which will enforce HTTPS for the Pega server and mashup. Note: The SameSite cookie may be set to None/Lax/Strict, based on the requirement. For mashups to work, SameSite should be set as None. To follow proper security standards, it should be set as Strict.
SR-D83053 · Issue 544268
SameSite cookie setting added for Mashup support in Google Chrome v80+
Resolved in Pega Version 8.2.6
The Google Chrome browser version 80 and above now treats SameSite with a blank value as "Lax" by default, causing mashup scenarios to break. In order to compensate for this change, support has been added for setting SameSite=None in Cookie Settings in the CSRF LP (DevStudio-> System-> Setting-> CrossSiteRequestForgery) which will enforce HTTPS for the Pega server and mashup. Note: The SameSite cookie may be set to None/Lax/Strict, based on the requirement. For mashups to work, SameSite should be set as None. To follow proper security standards, it should be set as Strict.
SR-D83192 · Issue 545057
JobScheduler DST handling updated
Resolved in Pega Version 8.2.6
When the locale being used changed out of Daylight Savings Time, scheduled jobs did run at the same local time as before but instead ran an hour earlier than expected. Investigation showed that jobscheduler calculated the next runtime based on the time difference from the cluster reference time and current time in milliseconds, and this offset in milliseconds was added to next run time. Since the cluster was started in DST, the job was running on same time due to the time difference. To resolve this, the system will use a calculation offset and set hours/minutes to nextRunTime object so that calendar lib handles daylight savings.
INC-220622 · Issue 711374
Libraries updated
Resolved in Pega Version 8.7.3
The following libraries have been updated to the most recent version: - commons-collections - cxf-rt-rs-security-oauth2 - derby - dom4j - google-oauth-client - groovy - jackson-databind - postgres - snakeyaml - spring-core - xmlsec The following library dependencies have been deprecated, excluded, and/or removed: - ant - bsh - commons-compress - gson - io.netty - jackson-mapper-asl - jdom - jdom2 - jdom-legacy - jetty-http - jetty-io - jetty-server - jetty-util - junrar - netty-handler - plexus - plexus-utils - xercesImpl - xstream
INC-221019 · Issue 725147
Modified timestamp query used by ClusterAndDBCleaner
Resolved in Pega Version 8.7.3
The job pyClusterAndDBCleaner was failing with the error "ORA-01861: literal does not match format string". This was traced to the sub-activity pzClearOldQueueProcessorBrokenMessages which was not able to remove broken items with encryption in an upgraded environment due to an incorrect timestamp format passed to the Oracle database. This has been resolved by modifying the query to use a timestamp built using INativeSqlBuilder which will include only the information necessary for the deletion of the item.
INC-224954 · Issue 727043
Enabled turning off general metrics when queue processing metrics are disabled
Resolved in Pega Version 8.7.3
A memory leak related to QPGeneralMetrics was consuming heap and causing performance issues. Investigation showed queue processor metrics were gathered even when disabled. To resolve this, turning off "General Metrics Handler" while turning off the QPGeneralMetrics has been enabled. Queue processors should now skip the process of collecting general metrics while running activities. This will prevent storing unused (and uncleared) metrics in memory and prevent heap exhaustion.
INC-225519 · Issue 724397
Improved handling for thread resolution issues
Resolved in Pega Version 8.7.3
Queue Processor/Dataflow was moving to STOPPED state due to failed records in its execution. Investigation showed there was a minor logic issue in the queue processor activity which allowed the Page-Remove step to be called even before the pages were actually created, and this has been resolved by improving the recovery from a cleared ThreadContainer which might cause thread resolution issues.