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
>
<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.
