I work in an environment that runs ATG (Oracle Commerce) 11.1 on Weblogic 12c and connects to an Endeca instance. In the Weblogic log files, I get a frequent IOException , which I believe has a decisive influence on the overall stability of the site. The error is as follows:
####<24 Nov 2015 2:47:39 PM> <Error> <HTTP> <SERVER-1> <instance-1> <[ACTIVE] ExecuteThread: '116' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1448369259872> <BEA-101019> <[ ServletContext@1433232248 [app:ATGProduction module:store path:null spec-version:3.0]] Servlet failed with an IOException. java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487) at weblogic.socket.NIOSocketMuxer$NIOOutputStream.writeInternal(NIOSocketMuxer.java:1064) at weblogic.socket.NIOSocketMuxer$NIOOutputStream.write(NIOSocketMuxer.java:983) at weblogic.servlet.internal.ChunkOutput.writeChunkTransfer(ChunkOutput.java:622) at weblogic.servlet.internal.ChunkOutput.writeChunks(ChunkOutput.java:587) at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:472) at weblogic.servlet.internal.CharsetChunkOutput.flush(CharsetChunkOutput.java:301) at weblogic.servlet.internal.ChunkOutput$3.checkForFlush(ChunkOutput.java:727) at weblogic.servlet.internal.CharsetChunkOutput.write(CharsetChunkOutput.java:203) at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:153) at weblogic.servlet.jsp.JspWriterImpl.write(JspWriterImpl.java:275) at jsp_servlet._tags._store.__contentitem_tag._jsp__tag2(__contentitem_tag.java:321) at jsp_servlet._tags._store.__contentitem_tag._jsp__tag1(__contentitem_tag.java:272) at jsp_servlet._tags._store.__contentitem_tag.doTag(__contentitem_tag.java:196) at jsp_servlet._cartridges._pageslot.__pageslot._jsp__tag6(__pageslot.java:412) at jsp_servlet._cartridges._pageslot.__pageslot._jsp__tag5(__pageslot.java:371) at jsp_servlet._cartridges._pageslot.__pageslot._jsp__tag2(__pageslot.java:258) at jsp_servlet._cartridges._pageslot.__pageslot._jspService(__pageslot.java:128) at weblogic.servlet.jsp.JspBase.service(JspBase.java:35) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:346) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:243) at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:587) at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:273)
An error in the contentitem.tag file contentitem.tag executed sequentially:
<%@ tag language="java" pageEncoding="UTF-8"%> <%@ include file="/include/taglibs.jspf" %> <%@ attribute name="contentItem" required="true" rtexprvalue="true" type="java.util.Map"%> <dsp:getvalueof var="include" value="${contentItem['@type']}" /> <c:choose> <c:when test="${empty contentItemKey && !empty include}"> <dsp:include page="/cartridges/${include}/${include}.jsp"> <dsp:param name="contentItem" value="${contentItem}"/> </dsp:include> </c:when> <c:when test="${!empty contentItemKey}"> <c:out value="${contentItem[contentItemKey]}" escapeXml="false" /> </c:when> </c:choose>
Would changing the ChunkSize parameter in Weblogic change? It is still at the default 4k level.
Is it a coincidence that the problem always appears in the contentitem.tag file, how do we unpack and process the contents associated with Endeca? A tag file is recursively called using the cartridges that it includes.
Any advice on how to solve this problem was appreciated.
Update:
By implicitly answering the question, we made significant progress in reducing (not eliminating) IOException after we realized that the <page-check-seconds> directive in weblogic.xml was inadvertently set to 0 (i.e., compiles pages for each request ) This led to multiple threads trying to compile the same page fragment. Stability has been greatly improved, but an IOException not been eradicated.
source share