Return-Path: Delivered-To: apmail-commons-issues-archive@locus.apache.org Received: (qmail 80724 invoked from network); 14 Apr 2008 20:08:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Apr 2008 20:08:07 -0000 Received: (qmail 61493 invoked by uid 500); 14 Apr 2008 20:08:06 -0000 Delivered-To: apmail-commons-issues-archive@commons.apache.org Received: (qmail 61416 invoked by uid 500); 14 Apr 2008 20:08:06 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 61407 invoked by uid 99); 14 Apr 2008 20:08:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Apr 2008 13:08:06 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Apr 2008 20:07:31 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id F03D7234C0D6 for ; Mon, 14 Apr 2008 13:05:04 -0700 (PDT) Message-ID: <77525556.1208203504983.JavaMail.jira@brutus> Date: Mon, 14 Apr 2008 13:05:04 -0700 (PDT) From: "F. Andy Seidl (JIRA)" To: issues@commons.apache.org Subject: [jira] Commented: (FILEUPLOAD-149) Intermittent file corruption on upload In-Reply-To: <10953473.1193244530599.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/FILEUPLOAD-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12588754#action_12588754 ] F. Andy Seidl commented on FILEUPLOAD-149: ------------------------------------------ Hi Jochen (and others): I recently re-tried FileUpload on the affected Linux servers after upgrading to the latest release version of commons-io, but the issues remain. I realize that Jochen does not believe these results, but I remain stumped as to why the same code runs on most of my servers but corrupts files on others. It must be some type of environmental issue, but like what? This is particularly nasty for me to debug (lacking any guidance or hypotheses) because I *only* see failures on a small number of production machines. I have not been able to reproduce these failures on a development system. As such, it is a very slow debugging cycle to deploy debugging code and do bug hunting on a production server. *Any* suggestions as to what might create the type of corruptions I am seeing (and I really am seeing them) would be greatly appreciated. Thank you, -- fas > Intermittent file corruption on upload > -------------------------------------- > > Key: FILEUPLOAD-149 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-149 > 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.