SR-B96377 · Issue 342936
Cassandra enhancements for multi-datacenter environments
Resolved in Pega Version 7.4
1) Locking has been added to the creation of Cassandra key/value table to support multi-datacenter configuration of Cassandra in DDS. 2) A new parameter called cassandra_java_home has been added to allow the use of a different java than that used for the web server. 3) Support has also been added for multi-datacenter configuration by way of the following configuration parameter which should be set in either prconfig.xml or the prpc command line, where datacentername is the name of the datacenter configured in the node's cassndra-dcrack.properties file:
SR-B96377 · Issue 342939
Cassandra enhancements for multi-datacenter environments
Resolved in Pega Version 7.4
1) Locking has been added to the creation of Cassandra key/value table to support multi-datacenter configuration of Cassandra in DDS. 2) A new parameter called cassandra_java_home has been added to allow the use of a different java than that used for the web server. 3) Support has also been added for multi-datacenter configuration by way of the following configuration parameter which should be set in either prconfig.xml or the prpc command line, where datacentername is the name of the datacenter configured in the node's cassndra-dcrack.properties file:
SR-B97064 · Issue 345331
Column size for property reference increased
Resolved in Pega Version 7.4
In an adaptive model where predictors have a long clipboard reference due to being located deep within the workpage (E.g. : .SubmissionData.PropertyLocation(1).BuildingInfo(1).LeftExposureAndDist), the model could be saved and run, but the models did not show up in the Adaptive Analytics portal. This was traced to adaptive model monitoring having a limit of 128 characters for the property reference column, and has been fixed by increasing the column size for pxInsName to 255 characters. In addition, the pzInsKey has been increased to 600 characters.
SR-C1507 · Issue 344564
Existing Kafka topic name used for connection
Resolved in Pega Version 7.4
When running a Kafka dataflow, Pega was using the dataset name instead of the topic name for the topic connection. This has been fixed, along with forcing a capital letter for the first character of the dataset name in order to ensure proper matching.
SR-C2352 · Issue 347253
Data join optimized for performance
Resolved in Pega Version 7.4
The data join implementation has been modified in order to improve performance for ADE applications built on Pega and based on DSM.
SR-C5585 · Issue 347734
Correct error messages shown for failed data flow records
Resolved in Pega Version 7.4
When running the data flow, the failed records were returned with incorrect error messages. In this case, the original exception generated by the CassandraBrowseByKeysOperations was not propagated to the caller. This has been fixed by adding the original exception to the one thrown to the caller.
SR-C6486 · Issue 349824
Check added for Kafka dataflow error handling
Resolved in Pega Version 7.4
When an event dataflow has failed because too many errors were detected, it is possible to continue it. However, it was noticed that the "continue" button had to be used twice: The first time, the dataflow failed again and the "Input record" was increased more than expected. For instance, if the event flow was sent 2 incorrect events, the "Input record" was increased by 3 instead of 1. The second time, the event dataflow was resumed correctly. Investigation showed that when a bad record is inserted into Kafka, a dummy error record is generated that has no information of the partition and position, so the data flow cannot update the partition table correctly. In order to correct this, the partition and position information will be given on the error record. The data flow execution has also been updated such that when there is an onError call, a check will be performed to assess whether the error originated on the primary source and an input record is present. If so, then the partition table will be updated from that record.
SR-C691 · Issue 349064
VBD reworked to retrieve IH DB metadata
Resolved in Pega Version 7.4
Campaign dashboard performance was slow when accessed via the Navigation bar button PRPC user configured for app server has restricted access to schema metadata. This causes VBD to be unable to build SQL query used to synchronize Actuals data set with Interaction History. It was possible to optionally configure vbd/useTableMapping = true in PR Config or DSS (owning RS: Pega-DecisionEngine) in order to force VBD to load IH database column metadata using Pega table info mapping instead of using database connection API, but the issue has now been fixed by reworking VBD to use Pega class/database mapping rules instead of JDBC DatabaseMetadata to retrieve IH fact/dim table columns.
SR-C8023 · Issue 350229
Updated dataflow used after pause/continue
Resolved in Pega Version 7.4
When using an event dataflow that has a Kafka dataset as the source, running the flow, pausing it, and importing updated rules was resulting in the resumed flow still using the old rules. This was a known limitation in the data flow metrics management where when a run was resumed, the previous metrics were "merged" with new metrics. In cases where the structure of a data flow changed between pause/resume, merge failed silently and new metrics were not saved to the database. The metric management has now been updated to merge metrics correctly: in case of a data flow structure update (e.g. shapes added/removed), after the data flow is run, stage metrics will be cleared up as it is not possible to match them with the new structure, and all other metrics will be properly resumed from the "paused" position (e.g. number of processed records, throughput etc.).
INC-126796 · Issue 561533
Modifications to getFunctionalServiceNodes process
Resolved in Pega Version 8.2.7
The count of the Interaction History write related threads was increasing rapidly and a stack trace indicated "waiting on condition" and "java.lang.Thread.State: WAITING (parking)" errors. Investigation showed that this was due to getFunctionalServiceNodes using Hazelcast to determine node status by making a service request on an installation with a very large number of nodes, causing thread locking. To resolve this, the implementation has been updated to avoid calling getFunctionalServiceNodes on save of Interaction History, instead using Cassandra and only calling getFunctionalServiceNodes on the master node, not on all nodes.