commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "F. Andy Seidl (JIRA)" <>
Subject [jira] Resolved: (FILEUPLOAD-149) Intermittent file corruption on upload
Date Mon, 12 May 2008 13:33:56 GMT


F. Andy Seidl resolved FILEUPLOAD-149.

    Resolution: Invalid

While the symptoms were real, the cause was outside (below) FileUpload.   Specifically, within
MultipartStream.makeAvailable() , the following function was violating its contract:

int bytesRead =, tail, bufSize- tail);

Under certain not-understood but repeatable circumstances, the call to read() was acting as
if tail==0 when it actually was non-zero (i.e., tail==pad).  When this occurred, new data
was written to the front of the buffer instead of tail bytes into the buffer.  The result
was tail bytes of data being dropped from the buffer, the new data being shifted to the front
of the buffer, and tail bytes of garbage being re-used at the end of the buffer--in short,
a corrupted file that retained its correct size (except for the even rarer occurrences when
 the lost bytes contained a boundary separator.)

Ultimately the problem was in the implementation of the input stream class, which in this
case, was com.caucho.server.connection.ServletInputStreamImpl, which is supplied by Resin.

I did not determine under what circumstances this stream implementation was failing, but noting
that read() was always returning 1460 bytes (a TCP packet size), even though the buffer was
4K, suggested that this was not a buffered implementation. I wrapped the raw input stream
in a BufferedInputStream (by overriding getInputStream in ServletRequestContext) and the problems

> Intermittent file corruption on upload
> --------------------------------------
>                 Key: FILEUPLOAD-149
>                 URL:
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.2
>         Environment: Linux (CentOS) server; all client platforms and browsers
>            Reporter: F. Andy Seidl
>            Priority: Critical
> I have been struggling for several weeks trying to track down the root cause
> of a sporadic file corruption problem using File Upload.  I'm really stumped
> at this point and welcome any suggestions as to avenues of debugging
> pursuit.
> Here's overview of the problem:
> I have eight Linux (CentOS) servers all running the same web application--a
> set of Java servlets using Resin as a servlet runner under Apache.  All
> servers were configured using the same script that installs jars,
> config files, etc.
> On three of the servers, File Upload works reliably.  On five of the
> servers, File Upload usually (but not always) leaves me with a corrupted file.
> Corrupted files are always the correct length but contain a relatively small
> percentage of scrambled bytes.  I looked for obvious patterns like newlines
> being altered or high-bit bytes being converted to or from UTF-8, but there
> is no obvious (to me, anyway) pattern in the failure.
> I have also tested with IE, FireFox, and Safari on both Windows and MacOS.
> The issue appears to be independent of client browser and OS.
> Looking at Java system properties, I notice that while the classpath and
> bootclasspath have the same jars lists on all servers, they are not listed
> in the same order (probably listed in directory order as the paths are
> constructed by a script that inspects lib directories.)
> Is anyone aware of classpath order dependencies that could break File
> Upload?
> Can anyone offer any suggestions about what *might* be breaking File Upload?
> Or what other questions I should be asking?  At the moment, I'm feeling
> rather stumped.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message