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.
SR-D27161 · Issue 503154
Step staus fail logic updated to handle agent activity exception
Resolved in Pega Version 8.2.4
Attempting to execute an advanced agent containing logic that set a step status to fail resulted in the error "Agent activity disabled due to execution errors; ErrorMsg: unable to execute agent: Cannot obtain a lock on instance as Requestor already has the lock ". This was traced to a backwards compatibility issue with previous work done to handle cases where agent activity requires authentication and agent has "bypass auth" flag set to false. Agent activity is not allowed to execute by the engine, and to show this scenario as exception case instead of showing it as running in admin studio, changes were made to rely on step status as the engine internally sets step status to false in this case. However, this inadvertently affected use cases where agent activity sets the status as fail in its logic. To resolve this, the system has been updated to handle the exception case and not consider StepStatus.
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.
SR-D28719 · Issue 505967
Null archive check added to set import process status
Resolved in Pega Version 8.2.4
After running a 'prpcServiceUtils.sh import' which failed due to a low-level null pointer error, the job "IMPORTREQUEST-2" then incorrectly showed the status as 'IN PROGRESS' instead of 'FAILED'. In this case, the null pointer exception occurred because two imports were unintentionally happening at the same time: the process copied up the same set of archives to the service export directory, but the first import processed an archive and deleted it so that the second process failed to find it. When it exited with the null pointer exception, the status was not set to 'failed'. To resolve this, a null archive check has been added which will set the status to 'failed' if the archive is unsupported, corrupt, or not there at all.
INC-196389 · Issue 690786
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.
INC-201335 · Issue 690733
ConfigurationReconciliationTask updated for greater compatibility
Resolved in Pega Version 8.7
After updating from Pega 8.3 to Pega 8.6, models which previously had learning and performance AUC greater than 0.7 reported an AUC of 0.5. This was traced to the update handling in ConfigurationReconciliationTask. AdmRuleBrowser does not perform ruleset resolution, so all rules were returned, for example the rule for model A in both the 08-01 and 08-03 ruleset. The system then iterated over all of the adaptive model rules returned by AdmRuleBrowser in order to assess whether a configuration update was necessary. The condition to update the model rule was met when either the config key did not exist (indicating a newly added configuration) or the model rule was "old" (version <2). For models generated in Pega 8.3 or earlier the version number for all rules must be 1, and the update to Pega 8.6 therefore caused the ConfigurationReconciliationTask to be applied to all adaptive model rules. To resolve this, the configuration update check in ConfigurationReconciliationTask has been removed.