Trace agents from the Agent Management landing page
Valid from Pega Version 7.2.2
You can now trace an agent on any node in the cluster from the Agent Management landing page without logging in to the individual nodes. From this landing page, you also specify when to trace an agent.
For more information, see Tracing agents.
Client page load statistic enhancements
Valid from Pega Version 7.2.2
The client page load statistic is the total elapsed time from when the user clicks to when the screen has finished rendering, including network time and time spent in the browser. This statistic gives you visibility into system performance, allowing you to address performance issues in a timely manner. The client page load statistic is now available for usage reporting through the Log-Usage class and in the System Management Application (SMA). In addition, a new alert, PEGA0069, is generated when the page load duration is greater than the threshold. The threshold is set by using the following prconfig.xml file setting:
<env name="alerts/browser/clientPageLoadTimeThreshold/warnMS" value="<milliseconds>" />
The default is 4000 milliseconds.
For more information, see PEGA0069 alert - Client page load time has exceed the alert threshold.
System starts slowly after upgrade or update on IBM DB2 for z/OS
Valid from Pega Version 7.2.2
Additional tables are added to upgraded and updated systems. If your system starts up very slowly after an upgrade or update, the database statistics on these new tables might not have generated correctly. To correct this issue and improve performance, your database administrator needs to manually rebuild the statistics for all tables in the rules schema.
Simplified support for external log management systems
Valid from Pega Version 7.2.2
Simplified support for external log management systems such as ELK (Elasticsearch, Logstash, Kibana) makes it easier to implement an external log management system. An external log management system can improve access to system log files that help diagnose and debug issues by eliminating the need to download log files from each node in the cluster.
For information about configuring ELK, see Configuring ELK for log management.
For information about using Kibana to view log files, see Pega logs in Kibana.
Clustering equal to none might cause errors
Valid from Pega Version 7.2.2
Some Pega 7 Platform features might not work when theidentification/cluster/protocolsetting in the prconfig.xml file is set to none. Some features that might not work are remote tracing and management actions on the node from the Requestor Management and Agent Management landing pages. Setting the clustering protocol to none is not recommended and will not be supported in a future Pega 7 Platform release.
Search reindexing is automatically triggered
Valid from Pega Version 7.2.2
Reindexing on index host nodes is now triggered automatically when no other index node exists in the cluster, eliminating the need for you to manually clean up old items and start reindexing. In addition, offline index host nodes are removed as index host nodes during normal shutdown and startup of any node in the cluster. As a result, you might have to add back a node as an index host node on the Search landing page. You can configure a node to always be an index host node or to never be an index host node by using the JVM -Dindex.directory option as described in Managing Elasticsearch index host nodes outside of the Search landing page.
You can turn off automatic reindexing by using the indexing/distributed/automodecleanupandreindex Dynamic System Setting.
Node classification feature
Valid from Pega Version 7.2.2
With the node classification feature, you can group production nodes by different node types to segregate nodes by their purpose. Currently, agents and listeners can be associated with node types. If you start a node with a specific node type, the node runs only the associated agents and listeners for that node type. This enhancement improves performance and optimizes resources.
For more information, see Configuring node types for agents and listeners, Mapping listeners to node types, and Mapping agents to node types.
Default quiesce strategy changed to immediate drain
Valid from Pega Version 7.2.2
The default quiesce strategy has been changed to immediate drain, which allows you to continue to access a quiescing node to perform actions until the node is removed from the load balancer, regardless of your user role. When immediate drain is enabled, and a node is in the quiesce state, the requestor state is saved after every interaction. After the node has been removed from the load balancer, the saved state can be used to restore the requestor state on a new node in the next interaction with the server.
You can change the quiesce strategy default to slow drain by modifying the value of the session/ha/quiesce/strategy setting in the prconfig.xml file to be slowDrain.
Disregard this startup error for Oracle Weblogic deployments
Valid from Pega Version 7.2.2
If you install, upgrade, or update your Oracle Weblogic application server to Pega 7.2.2, disregard the error stack that begins with text similar to the following:
ERROR - WebLogic Server 12.1.3.0.0 Wed May 21 18:53:34 PDT 2014 1604337 Oracle WebLogic Server Module Dependencies 12.1 Tue Mar 11 15:35:15 MDT 2014 WebLogic Jersey Server Integration 3.0 Fri Feb 21 10:55:11 UTC 2014 must use JDK 1.8+ with WebSocket
2016-11-07 06:13:01,690 [ WIN-L3EEURCNCP1] [ STANDARD] (pr.DefaultAsyncSupportResolver) ERROR - Real error: Unable to configure jsr356 at that stage. ServerContainer is null
This message appears because the Pega 7.2.2 real-time notification feature initially tries to use WebSocket and then falls back to long polling. The Pega 7 Platform does not support WebSocket for Oracle Weblogic servers, and instead uses long polling for real-time notifications.
Disregard this Java script console message
Valid from Pega Version 7.2.2
Pega 7.2.2 introduced real-time notifications by using Comet technologies such as WebSocket and long polling. WebSocket provides the best results, but both WebSocket and non-blocking long polling must be supported by your application server. If your application server does not support WebSocket, you might see a JavaScript error that begins with text that is similar to the following text:
WebSocket connection to 'ws://vnbamdevapp01:8080/prweb/PRPushServlet/... Error during WebSocket handshake: Unexpected response code: 501_getWebSocket @ pzpega_ui_messaging_1802554968!!.js:1195 pzpega_ui_messaging_1802554968!!.js:3265 Websocket closed, reason: Connection was closed abnormally (that is, with no close frame being sent). - wasClean: falselog @ pzpega_ui_messaging_1802554968!!.js:3265 pzpega_ui_messaging_1802554968!!.js:3265 Websocket failed on first connection attempt. Downgrading to long-polling and resending
You can disregard this message.
However, to take advantage of the improvements to real-time notifications, enable support for WebSocket:
- For IBM WebSphere Application Server Liberty Core, see your deployment guide for instructions on configuring the application server.
- For Red Hat JBoss, see your deployment guide for instructions on enabling WebSocket support.
- For Apache Tomcat application servers, consider upgrading to Apache Tomcat 7.0.53 or later which supports WebSocket.