INC-143121 · Issue 610732
Timeout for loading predictors made configurable
Resolved in Pega Version 8.3.6
When using an extremely large number of predictors, the Report definition pzADMPredictorsFilter was suffering timeouts due to the time for loading predictors from the database exceeding the time threshold allowed. This has been resolved by marking the rule as editable to allow custom setting of the threshold according to need.
INC-148899 · Issue 615702
Adaptive models update correctly
Resolved in Pega Version 8.3.6
Some models had the recorded responses column updated, but the models (number of Positive, Negative and Processed Responses) were not updated. Investigation showed that deleting the modelRuleConfiguration through the stateManager/client did not delete modelFactories related to the configuration. If a new configuration came in with a different algorithm, the update issue occurred. This has been resolved by reseting the configuration according to its factory in that specific case.
INC-155822 · Issue 618267
Locking added to avoid null pointer error for auto-populate property
Resolved in Pega Version 8.3.6
After configuring the auto populate property "OrgProduct" which referred to a data page, the system experiencing heavy load led to the property not getting properly initialized. This resulted in a WrongModeException and NullPointerException. To resolve this, the system has been updated to lock the requestor when Queue Processors execute their activity. This will prevent race conditions and concurrent modifications if other threads are accessing the same requestor.
INC-157629 · Issue 626633
Duplicate key exception resolved for adaptive model
Resolved in Pega Version 8.3.6
During the model snapshot update, a DuplicateKeyException was generated while trying to insert a record in to the predictor table. This did not affect the model's learning, but did appear ion the model monitoring report. This was traced to a local scenario of having the same outcome values defined on the model with different cases (Accept and accept). All predictors used in an Adaptive model are inserted into the model monitoring tables as a part of the monitoring job: because the monitoring tables are not case sensitive, this lead to a unique constraint exception since there were multiple IH predictors with the same name. To resolve this, validation has been added which will skip adding duplicates from new responses.
INC-160331 · Issue 628710
ML model continue tag error changed to debug logging
Resolved in Pega Version 8.3.6
Log entries were seen indicating "The continue tag is found without a start tag for window Line1 1234567890 in text". This appeared to be coming from the MLCommand java class. Investigation showed this occurred when the ML model believed a portion of the text (token) was a continuation of the entity because it has not found the starting part of the entity. This situation is not currently treated as a valid output, so an update has been made to change the logging level from error to debug for this case.
SR-69015 · Issue 619995
Unescaping characters implemented for expressions
Resolved in Pega Version 8.3.6, Resolved in Pega Version 8.4.4, Resolved in Pega Version 8.5.3, Resolved in Pega Version 8.6
An issue where expression builder statements were evaluated differently at runtime than at testing has been resolved. Pega Platform expressions with String literals(that is, sequences of characters enclosed in quotation marks) now unescape characters in strategy shapes such as Set Property or Filter.
SR-D39972 · Issue 513459
UpgradeOnOpen updated to use property set
Resolved in Pega Version 8.3.2
After upgrade, using the revalidate & save wizard on MapValue rules (Rule-Obj-MapValue) generated null pointer exceptions in the tracer file and rules failed with bad status. This was traced to changes made in the Java step of UpgradeOnOpen that used the getReference() method, and has been resolved by updating the UpgradeOnOpen activity in the Rule-obj-Mapvalue class to use property set.
SR-D41207 · Issue 512086
Fallover stategy added to chat routing to keep event processor running
Resolved in Pega Version 8.3.2
Chats were becoming stuck in the queue and end users were not able to connect with the customer service representative. An excessive number of queued items were observed in a Queue Processor named "EventProcessor". This was traced to the setting "Browse from the offset" having been removed because of a retention policy. This resulted in "Browse from the end of the stream" being used instead even though browse should start from the earliest known offset. To resolve this, Stream Producer will be cached based on topic, and Stream consumer will fall over to an earliest strategy in case the requested offset isn't found so the event queue will be handled in a timely manner.
SR-D42451 · Issue 518066
ExecuteRDB call updated to use NativeSQL for blob
Resolved in Pega Version 8.3.2
After creating a test activity to clear data set records that used the DataSet-Execute method and passed the data set name and truncate operation, only 51 records were deleted in a single run when the data set had more than 51 records. Investigation showed that for blob tables, the database truncate operation was using executeRDB with an empty results page, i.e. it didn't specify pyMaxRecords, which on some databases might have limited the number affected records. To resolve this, the executeRDB call in the database truncate operation has been modified to use NativeSQL for blob tables.
SR-D43912 · Issue 509736
Fallover stategy added to chat routing to keep event processor running
Resolved in Pega Version 8.3.2
Chats were becoming stuck in the queue and end users were not able to connect with the customer service representative. An excessive number of queued items were observed in a Queue Processor named "EventProcessor". This was traced to the setting "Browse from the offset" having been removed because of a retention policy. This resulted in "Browse from the end of the stream" being used instead even though browse should start from the earliest known offset. To resolve this, Stream Producer will be cached based on topic, and Stream consumer will fall over to an earliest strategy in case the requested offset isn't found so the event queue will be handled in a timely manner.