java.net.SocketException-Socket Write Error

Discussions

Web tier: servlets, JSP, Web frameworks: java.net.SocketException-Socket Write Error

  1. java.net.SocketException-Socket Write Error (3 messages)


    Some JSP pages throwing
    java.net.SocketException: socket write error (code=10053) at java.net.SocketOutputStream.socketWrite(Native Method)
    eventhough it presented everything. I'm using EJB as buisness layer. Thankx in Advance, for giving solution to fix it.
  2. I'm seeing similar problems using JDBC from within JBs that are utilized from JSPs. I've seen it happen on various AppServers (Tomcat, Orion and WebLogic), Databases (SQL Server, Oracle and Pervasive.SQL) and browsers (IE5.5, NS4.75 and NS6).

    It looks like the browser's JRE is choking. It mainly happens to me when I refresh the same page several times in rapid succession, especially if the JB is returning a lot of data to the JSP.

    I would also appreciate any insights about how I can avoid this difficulty.

    Thanks,
    Jeff
  3. Hi folks,
    The error is harmless. The best way to overcome this problem is to install WLS ServicePack 8.

    The issue is that the client is not accepting the response from the server.

    You can see this if u keep pressing the refresh button contineously or click the stop button when the server is responding to your request..
    Cheers
    Shekar
  4. Good to know there's a patch for WLS. However, I've seen this same error with Tomcat, Orion and JRun. And while it may be harmless, I worry about the performance and resource utilization issues associated with it (more on this follows).

    Last weekend, I found that the source of my problem was purely IE5 and XML. I cobbled a way to test this with Netscape and this problem does not happen at all.

    I'm basically using JSPs to generate pure XML pages with references to XSL stylesheets so that IE5 can do the transformations (instead of using server resources). In the following description, I don't mean to suggest that I've debugged into IE5 and understand how the IE5 engine actually works--rather I'm describing what seems to be the behavior.

    Here's the scenario. You're looking at a web page with a link to a JSP. When you click this link, the browser requests the JSP page. This JSP emits a page directive to change the contentType to "text/xml". It seems that as soon as IE5 gets this contentType switch, it abruptly drops the existing connection to the server and immediately requests the same page again.

    Well, this can cause problems on the server. For example, if the JSP page takes a non-trivial amount of time to render itself, then the socket write error will almost always occur since the 'peer' (IE5 in the case) always abruptly terminates the first connection to start the second. If the first JSP page request had time to open a database connection (before the second page request yanked the rug), then the socket write error may also interrupt the JSP's ability to execute enough logic to get to close the database connection at the bottom of the page. This tends to leave database connections hanging until they timeout.

    In my case, I was using a frameset which contained four JSPs--each of which emitted XML. In this case, each time I pressed F5, I saw four complete sets of "Socket Write Error" tracedumps along with stranding four different database connections. Imagine this problem in a scenario where hundreds or even thousands of customers were requesting updates to this frameset. There are two painpoints. First is the penalty of forcing the server to deal with needless exception handling four times per reload action (a performance penalty associated with dumping the stacktrace to the log file). Second are the resources held in limbo by stranded database connections (which looks like a big memory leak).

    My workaround is to avoid sending a pure XML page to IE5. Instead I send the XML data in an XML data island and use JavaScript to do the transformation. [Sample code follows] IE5 is still doing the transformation but since we're sending a real HTML file with embedded XML, instead of a real XML file, we don't have IE5 requesting every page twice.

    I would prefer to be sending pure XML/XSL to the browsers that can handle it. But even when/if this problem is fixed by MS, we still have to accommodate the millions of IE5 installations that don't have the patch. So this workaround is likely to stay online for a long time in my apps.

    I guess you could say that instead of fixing the problem, I'm avoiding the situation that leads to the problem in the first place.

    Cheers,
    Jeff

    <HTML>
    <HEAD>
    <XML id="xslTransform" src="http://<%=request.getServerName()%>/Whatever/Style/ClassData.xsl">>
    <XML id="xmlData">
    <root>
    <!-- This JSP file emits the pure XML data for this page -->
    <jsp:include page="ClassData.jsp" flush="true" />
    </root>
    </XML>
    <script language="JavaScript">
    function doInitPage()
    {
      oData = xmlData.XMLDocument;
      document.all("InsertHere").innerHTML =
        oData.transformNode(xslTransform.XMLDocument);
    }
    </script>
    <link REL="STYLESHEET" TYPE="text/css"
      HREF="http://<%=request.getServerName()%>/Whatever/Style/ClassResources.css" />
    </HEAD>
    <body onload="doInitPage()" CLASS="NormalText" bgcolor="white" topmargin="0" bottommargin="0" leftmargin="0" rightmargin="0">
    <SPAN ID="InsertHere"></SPAN>
    </BODY>
    </HTML>

    Another variation is to have the JS actually replace the entire BODY section of the page. This would let the XSL file have complete control over the attributes of the Body tag. In my case, this wasn't necessary.