Support Article
Cloud Postgres 9.1 slow loading of Data Type compositions.
SA-9365
Summary
Customer experiencing issues when opening Data Objects, such as displaying the properties of a class (the example scenario showed 2 minutes to load this Data Type).
It seems that the problem is database related, maybe indexes are missing. It's a Postgres Instance on a split schema.
Error Messages
ClientAbortException: java.net.SocketException: Broken pipe
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:406)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:352)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:303)
at org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:108)
at com.pega.jcraft.jzlib.DeflaterOutputStream.close(DeflaterOutputStream.java:122)
at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
Steps to Reproduce
Not Listed.
Root Cause
The root cause of this problem is defect/misconfiguration in the operating environment.
In general the guardrail queries are complex. The query running slow has nothing to do with custom rule tables. It just depends on the data (number of rules in the system and the number of warnings for all these rules).
Note that if the data is of reasonable size and the statistics on the tables are up to date, they don't take long and it should get the required data in less than 2 seconds.
In 7.1.6, schema changes were introduced to make these queries execute faster. These schema changes include two new columns in the table pr4_rule_vw table in the rules schema.
The population of data in pr4_rule_vw table happens through database triggers defined for each rule table shipped. Since frameworks and customers can have their own rule types mapped to a table which is not shipped out of the box by PRPC, we cannot leverage this performance benefit in those scenarios unless they make the same modifications to their rule table triggers which we have done for ours. Thus, the prconfig setting mentioned below is therefore disabled by default.
Resolution
This issue is resolved through the following local change:
The Team changed the parameter:
reporting/useLayerCakeSchemaChanges in prconfig.xml to true and restarted.
Published June 12, 2015 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.