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-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.