INC-199303 · Issue 690629
Guided Tour working from Actions menu
Resolved in Pega Version 8.7
After updating from Pega 8.4 to Pega 8.5, "Manage a Guided Tour" was no longer working under a local action when called from the Actions menu on a work object. An unspecified error message appeared in the tracer. Investigation showed there was a null pointer error caused by the menu being invoked on an invalid page, and this was traced to updated authentication requirements: registration at the portal is not reliable as it is thread-scoped and run only once. The thread name is not guaranteed to stay the same so subsequent invocations of the tour activities failed. This has been resolved by modifying the call registration function to handle the security issues related to the generation of the menu path.
INC-182776 · Issue 666941
CheckFlowDependencies updated for auto-instantiated child cases
Resolved in Pega Version 8.7
A parent case with more than one child case was producing an unexpected behavior during the child case creation process. The first child case was instantiated at the correct point of the case stage based on its dependency condition, but the following cases were instantiated at the same point where the first child case was created irrespective of the dependency conditions defined in the other child cases. Investigation showed that the pxCheckFlowDependencies activity called from the Resolve activity was removing the named pages "pyTopCaseMap" "pyTopCaseWork" which are required for starting and validating configured auto-instantiate child cases in the pzCanStart function. To resolve this, an update has been made to CheckFlowDependencies which will use the activity "pzResolveCaseHierarchyMap" for removing the "pyTopCaseMap" and "pyTopCaseWork" pages based on DependencyType.
INC-190070 · Issue 676643
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-193153 · Issue 686293
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-201338 · Issue 690896
Restored local blocking queue cache
Resolved in Pega Version 8.7
After update, it was not possible to bring up secondary VBD nodes after restarting. Investigation traced this to earlier work done to resolve a memory leak issue, in which stale entries for local blocking queues were removed from cache. This resulted in modifying the queue listener logic to use "cache.getQueueIfPresent(jobId)" instead of "cache.getQueue(jobId)". Because the listener was not creating the cache if it was not present and the cache which held the local blocking queue didn't have the entry for the current remote execution job ID, the caller of the remote execution on Node2 ended up in blocking state forever, waiting on the local blocking queue. To resolve this, the code has been updated to ensure the blocking queue is created and stored in the local queue cache before publishing the remote job message.
INC-172675 · Issue 649455
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-185322 · Issue 668321
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-186898 · Issue 670313
Configuration added for extending queue processor timeout
Resolved in Pega Version 8.7
Alerts for queue processor (QP) items which took more than 15 minutes to run could result in the system marking the node as 'unhealthy'. In environments with Pega Health Check enabled, this would shut down the node gracefully. It was not possible to change this default as it was hardcoded. In order to support systems that may have custom processes that run beyond 15 minutes, a a new setting has been exposed that allows configuration of the interval after which a node with long-running queue processor is marked as unhealthy and is restarted. By default this remains 900000 milliseconds / 900 seconds / 15 minutes, but it may be adjusted up to 24 hours to avoid premature node shutdown. The stale thread detection mechanism will take that setting into account and use the provided value or default to 15 minutes if the value was not provided. In addition, the threshold's units in the UI have been changed from ms to seconds.
INC-152647 · Issue 609605
Email Listener auto-reply evaluation updated
Resolved in Pega Version 8.5.3
After upgrade, messages were being read but not getting processed for a specific Email listener (RCEmailListerner). The error "Email flagged as an autoreply email and will not be processed" appeared in the logs. Previously, an email was not considered to be an auto-reply only when the 'auto-submitted' header didn't exist or existed with value 'no'. This caused issues with auto-forward or auto-redirect emails where 'auto-submitted:auto-generated' could be in the header. Due to this, email was marked as auto-reply and email listener stopped processing it. To resolve this, the system has been modified to mark the message as auto-reply if it finds 'auto-submitted: auto-replied' in the header, but not 'auto-submitted:auto-generated'.
INC-157081 · Issue 623806
Email Listener auto-reply evaluation updated
Resolved in Pega Version 8.5.3
After upgrade, messages were being read but not getting processed for a specific Email listener (RCEmailListerner). The error "Email flagged as an autoreply email and will not be processed" appeared in the logs. Previously, an email was not considered to be an auto-reply only when the 'auto-submitted' header didn't exist or existed with value 'no'. This caused issues with auto-forward or auto-redirect emails where 'auto-submitted:auto-generated' could be in the header. Due to this, email was marked as auto-reply and email listener stopped processing it. To resolve this, the system has been modified to mark the message as auto-reply if it finds 'auto-submitted: auto-replied' in the header, but not 'auto-submitted:auto-generated'.