Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <49667A85.50702@compulsivecreative.com>
Date: Thu, 08 Jan 2009 14:13:25 -0800
From: Alan Chaney <alan@compulsivecreative.com>
Reply-To: alan@compulsivecreative.com
Organization: Paula Hollywood, Inc.
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080505)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: File upload fails
References: <21360958.post@talk.nabble.com>
 <49666FE6.1060804@compulsivecreative.com> <21361472.post@talk.nabble.com>
In-Reply-To: <21361472.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


javacle wrote:
> The file is about 30Mbytes 
> .. I get the same error uploading from the office on the same LAN as the
> server.
Ok - not likely to be a problem with the remote connection, then.

What do you see in your browser when the upload fails? Have you got any 
browser debugging - if you are using Firefox you can easily add the 
'LiveHttpHeaders' plugin which I find very useful.

What happens inside your application following the upload? Is there a 
significant period of processing in the same thread as the servlet 
doGet? If so, its possible that your connection is timing out.

As you can simulate the problem in your office, what happens if you 
DON'T restart tomcat after you get the connection issue? If you just 
leave it for a little while can you then upload again?


> Browser is (I think) always MSIE 6 .. but maybe sometimes Mozilla .. that's
> something to check.
> I will look into wireshark. 

Having a monitor on the connection will be useful. You should be able to 
install wireshark from your distro. I assume that as you are using MSIE 
then your dev. system is a PC? I develop on linux and don't know of any
particular network monitor to recommend.

HTH

Alan


> 
> 
> 
> Alan Chaney wrote:
>> How big is the file?
>>
>> "Connection reset" is commonly caused by the the client dropping the 
>> connection. This could be because of connectivity problems - for 
>> example, issues with the clients ISP.
>>
>> I have had problems with specific browsers over this as well (our site 
>> has dozens of large mpeg and jpeg uploads each day). The worst culprit 
>> proved to be Safari 3 on a Mac. Is the upload done with SSL?
>>
>> I doubt that restarting the server makes any difference one way or the 
>> other. Why not get the client to test with a non-urgent file and a 
>> non-urgent time  when you have a chance to fault-find? Also, you may 
>> want to watch the upload with something like wireshark to see exactly 
>> what is happening and when.
>>
>> Regards
>>
>> Alan Chaney
>>
>>
>> javacle wrote:
>>> <p>We have a customer who uploads a file on a daily basis.
>>> Usually it works, but about once every two weeks it fails with this error
>>> in
>>> the log :
>>> <p>org.apache.commons.fileupload.FileUploadException: Processing of
>>> multipart/form-data request failed. Connection reset
>>> <p>After restarting tomcat, sometimes three times, it eventually works.
>>> Whether the restarting is significant or just the passage of time that
>>> clears some other fault I dont know .. there is always a panic to get it
>>> working
>>>
>>> <p>The customer is on the other side of the continent, but today she
>>> emailed
>>> the file to me and I had the same error trying to upload her file from
>>> the
>>> office the first time (i.e. same building as server). So that would seem
>>> to
>>> eliminate long-distance network latency/timeout as a factor.
>>>
>>> <p>Nothing I am aware of has changed since the last time it worked,
>>> however
>>> something may have changed in the network, or on the server, without
>>> being
>>> noticed.
>>>
>>> Any advice would be appreciated
>>>
>>> tomcat 5.5, jre 1.4.2, Red Hat Enterprise Linux ES release 4 (Nahant)
>>> Kernel
>>> 2.6.9-5.ELsmp on an i686
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org