Hello
After posting this question to the Commons mailing list, I have been
advised to "ask the tomcat folks."
I am using Commons FileUpload 1.1 to manage HTTP POST uploads with
Tomcat running as a JkMount'ed service of Apache
I am trying to analyze the strain on memory when many large files are
being uploaded from different clients simultaneously
I have two questions:
1) Before a POST'ed file upload reaches FileUpload, is all or part of
it already cached somewhere on the server's drive space or memory, or
does it arrive from the network directly to FileUpload for parsing?
The latter would be desirable, as each uploaded file would get
written directly to the temp directory as it arrives over the
network, with no additional overhead. I do see my temp file growing
steadily as the upload proceeds. Is this the only place on the server
where resources are being allocated for this file upload? Can someone
verify/amend/ provide more details?
2) I tried uploading a file whose size exceeds the max file size I
set in my test JSP page. The JSP handles the upload with FileUpload,
and writes a log file of activity with time-stamps. Checking the log,
I see that my page throws the SizeLimitExceededException almost
immediately after the client's POST reaches the server. Yet the
client browser sits there and waits for roughly the amount of time a
full upload would take, and only then does the browser display the
SizeLimitExceededException. The wait is longer for larger files. Can
someone explain exactly what is happening during this time interval
between the exception being thrown on the server and the exception
appearing on the client? Is the file actually being uploaded
somewhere to the server after the SizeLimitExceededException is
thrown? If so, where is the upload going and whose memory or disk
resources are being utilized? Note that FileUpload's temp directory
does not show any temp file growing when this exception is thrown.
Yet there does seem to be some network activity between the client
and the server, but I am baffled as to what it could be and what its
implications might be.
Thank-you
Nick Didkovsky
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
