Possible effects of writing large byte arrays to an output stream?

private static void writeData( byte[] file, HttpServletResponse response )
    throws IOException
{
    ....
    // Send the data
    response.setContentLength(file.length);
    response.getOutputStream().write(file);
}

Recently, I've found in IE8 that some connections close while requesting files to download. This is the relevant piece of source in code, and I was wondering if writing large byte arrays all at once to the response output stream could cause this issue. The issue is very much non-reproducible, and I've often seen the pattern of writing a certain number of bytes at a time, versus all at once, to avoid MTU issues, or something like that.

Could this code be responsible for my intermittent IE issues? If so, why, and why only in IE?

Edit:

I tried using Cache-Control: no-cache, and the results were catastrophic in IE.

Request:

POST /myapplication/someAction.do?step=none&SAct=none HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, */*
Referer: https://myhost.myhost.com/myapplication/someAction.do?queryString=something
Accept-Language: en-US
User-Agent: Mozilla/4开发者_StackOverflow.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: myhost.myhost.com
Content-Length: 1644
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: JSESSIONID=GnvHMYyGx9QrmpVQfBSgNXnPM8nQJ21dT82KhmSSTXRRT1mgB8tP!299858932; [truncated]

Response:

HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Tue, 21 Sep 2010 18:00:56 GMT
Transfer-Encoding: chunked
Content-Type: application/ZIP
Content-Disposition: inline; filename=ActivityReport.ZIP
X-Powered-By: Servlet/2.5 JSP/2.1

Are you setting response's caching information? (dates, cache-control, etc.)

I've seen this behavior in IE a lot, and always has to do with IE's implementation of caching, instead of sending a HEAD request to check contents' validity, it sends the full GET request and then uses headers to determine the validity of its cached content, if it decides the cached version is valid, then just closes the connection, so a lot of "broken pipe" style errors show up on server side.

To verify this is the case, try sending cache control headers so IE always has to download the full content.

The pattern of writes (and flushes) made by the application can have an effect on the way packets are formed and sent, but this seems like the best possible set up: the kernel has complete information about the data to be sent from the beginning, and has freedom to choose the optimal packet-ization of the data.

It seems unlikely that this would be the cause of a client problem. Sending chunked output with potential to flush a lot of tiny packets would be a lot more suspicious.