Skip to Main Content
  • Questions
  • APEX 5.0 ORDS 2- Tomcat 7 - Errors on tomcat log and performance issues

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Sebastien.

Asked: November 08, 2016 - 1:12 pm UTC

Last updated: November 09, 2016 - 6:13 am UTC

Version: APEX 5.0

Viewed 1000+ times

You Asked

Hi Tom,

We have implemented Apex 5.0 as our new Developing tool which is a real great tool.
The configuration is on HP/UX, tomcat, ORDS and APEX on Oracle 11g r2.

We have 4 environnements (dev, qualification, preprod, prod).

On the 3 first envs (dev, qualif, preprod) we have no problems with it, there are no performance issue.

But on the production (which is on RAC as the preprod env), we have some latency issues that don't exist on the others.

Can you give me some directions to investigate ? because on the database there is nothing strange.
What is really strange is that the Apex sign in page and IDE (for developers), is really slower in production than in other environnements.
So we can't point our application...
The servers where Apex, tomcat and ORDS have huge capacities.
Here is the JDBC conf :
<entry key="jdbc.DriverType">thin</entry>
<entry key="jdbc.InactivityTimeout">1800</entry>
<entry key="jdbc.InitialLimit">10</entry>
<entry key="jdbc.MaxConnectionReuseCount">1000</entry>
<entry key="jdbc.MaxLimit">100</entry>
<entry key="jdbc.MaxStatementsLimit">100</entry>
<entry key="jdbc.MinLimit">1</entry>
<entry key="jdbc.statementTimeout">900</entry>

Is the RAC may produce APEX performance issues ? (whereas in preprod which is in RAC too, we don't have same issues...).

So if you have points to check to improve the response time, i take it !



And a second point (but this one is one every env), is inside the catalina.out log from tomcat where APEX is, we have this error several times a day :

Nov 8, 2016 12:02:52 PM oracle.dbtools.apex.ModApexContext write
SEVERE: null
ClientAbortException: java.net.SocketException: Broken pipe (errno:32)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:369)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:448)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:363)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:392)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:381)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89)
at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:83)
at oracle.dbtools.rt.web.WebErrorResponse$DeferErrorOuput.write(WebErrorResponse.java:255)
at oracle.dbtools.apex.ModApexContext.write(ModApexContext.java:240)
at oracle.dbtools.apex.ModApexContext.write(ModApexContext.java:198)
at oracle.dbtools.apex.ModApex.handleRequest(ModApex.java:232)
at oracle.dbtools.apex.ModApex.doGet(ModApex.java:97)
at oracle.dbtools.apex.ModApex.service(ModApex.java:301)
at oracle.dbtools.rt.web.HttpEndpointBase.modApex(HttpEndpointBase.java:350)
at oracle.dbtools.rt.web.HttpEndpointBase.service(HttpEndpointBase.java:132)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:682)
Caused by: java.net.SocketException: Broken pipe (errno:32)
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:97)
at java.net.SocketOutputStream.write(SocketOutputStream.java:141)
at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:761)
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:448)
at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:363)
at org.apache.coyote.http11.InternalOutputBuffer$OutputStreamOutputBuffer.doWrite(InternalOutputBuffer.java:785)
at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:126)
at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:598)
at org.apache.coyote.Response.doWrite(Response.java:533)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
... 27 more

And I can't see where it come from.
Do you have already experience this ? Or can you guide me to solve this ?

Thank you for your feedback.








and Connor said...

My hypothesis is that potential areas are

(a) middle tier layer (some of configuration issue), or network connectivity to database

or

(b) database issue.

I cant help you with (a) :-) but for (b), when someone does a slow login, check the database for long active sessions, or take an AWR snapshot just before and just after. Then we can at least confirm if its database or not.

If you dont see anything at database level, then I'd say it time to speak to Support, or post on the ORDS forum

https://community.oracle.com/community/database/developer-tools/oracle_rest_data_services

where they can probably suggest some ords tier tracing.

Hope this helps.

Is this answer out of date? If it is, please let us know via a Comment

More to Explore

Performance

Get all the information about database performance in the Database Performance guide.