5

I'm working 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 knock-on effect on the overall stability of the site. The error is as follow:

####<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)

The error happens consistently in the contentitem.tag file, which is as follow:

<%@ 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 be of any benefit? It is still at the default 4k at the moment.

Is it a coincidence that the issue always appears in the contentitem.tag file which is how we unpack and render Endeca related content? The tag file gets called recursively by the cartridges it includes.

Any advice on how to resolve this issue, appreciated.

Update:

While not answering the question explicitly, we've made significant strides into reducing (not eliminating) the IOException once we realised that the <page-check-seconds> directive in the weblogic.xml was inadvertently set to 0 (ie. compile pages on every request). This resulted in multiple threads trying to compile the same page fragment. Stability has been greatly improved but the IOException has not been eradicated.

4

0 回答 0