AppServer or Web App error (9.0.4) and BROKEN PIPE

Question

Hi,
I'm still using 9.0.4, and have started getting the following message in the base server.log of the Oracle Container.....
07/12/16 21:18:33 Internal error in HttpServer
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at com.evermind.server.http.EvermindServletOutputStream.write(EvermindServletOutputStream.java:216)
at com.evermind.server.http.EvermindServletOutputStream.write(EvermindServletOutputStream.java:151)
at com.evermind.server.http.EvermindServletOutputStream.write(EvermindServletOutputStream.java:146)
at com.evermind.server.http.EvermindHttpServletResponse.handleException(EvermindHttpServletResponse.java:1743)
at com.evermind.server.http.EvermindHttpServletResponse.handleException(EvermindHttpServletResponse.java:1572)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:803)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)
It's happening a lot, but I can't see any impact when using our web apps. Looking at my three most used web apps, I see the same error appearing at identical times in the individual log files, but they are all using different pages, so don't think they are 'causing' this prob.
Does anyone think I have something wrong with the basic application server, or is this indeed an issue with a particular web application that's spreading it's error to other web apps? Example of the error in a web app below.....and what is a Broken Pipe error?
Thanks in advance
Iain
07/12/16 21:18:33 web: Broken pipe
07/12/16 21:18:33 web: Servlet error
java.lang.ArrayIndexOutOfBoundsException
     at java.lang.System.arraycopy(Native Method)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.EvermindServletOutputStream.write(EvermindServletOutputStream.java:216)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.EvermindJSPWriter.writeOut(EvermindJSPWriter.java:456)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.EvermindJSPWriter.jspflush(EvermindJSPWriter.java:373)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.EvermindJSPWriter.write(EvermindJSPWriter.java:522)
     at com.evermind[Oracle Application Server Containers for J2EE 10g (9.0.4.0.0)].server.http.EvermindJSPWriter.write(EvermindJSPWriter.java:447)
     at observations.first_2d_observationsYR._jspService(_first_2d_observationsYR.java:174)

Answer 1

Raju --
Thanks for the intelligent posting on a difficult issue for you.
I wasn't aware of anything specifically being introduced that prevented the bootclasspath technique from working** in the 904 release.
For 904, the bootclasspath needs to be put in the start parameters tag of the java-options tag.
<process-type id="home" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" ... -Xbootclasspath/a:/java/lib/xerces.jar"/>
</category>
</module-data>
</process-type>
You can also try copying the xerces.jar into the jre/lib/ext directory so it's loaded by the system classloader and see if that works**. This will put xerces at the extension level so
**these workarounds are not supported and will put you in an unsupported situation if a problem occurs.
The good news is that have taken steps to clearly enable the separation of container versus appplication class spaces in thenext production release (10.1.3) of OC4J. We will be providing a new classloading model which cleanly separates the two namespaces and allows applications to provide their own versions or distributions of class libraries with no collisions with the OC4J runtime libraries.
I don't know of any easy ways to do what you need -- other than reworking the app to use JAXP so that the parser implementation used is pluggable as you kind of allude to. If it was possible, I'd do that rather than hard coding in the use of the Oracle XML parser.
But just to reiterate, switching in xerces at the bootclasspath level is not a supported operation since it may have an effect on the OC4J runtime operation.
cheers
-steve-