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).
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.
<XML id="xslTransform" src="http://<%=request.getServerName()%>/Whatever/Style/ClassData.xsl">
<!-- This JSP file emits the pure XML data for this page -->
<jsp:include page="ClassData.jsp" flush="true" />
oData = xmlData.XMLDocument;
<link REL="STYLESHEET" TYPE="text/css"
<body onload="doInitPage()" CLASS="NormalText" bgcolor="white" topmargin="0" bottommargin="0" leftmargin="0" rightmargin="0">
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.