Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of DJohnson@desknetinc.com
 designates 69.38.138.84 as permitted sender)
In-Reply-To: <455CB8F3.6050800@decoursey.net>
MIME-Version: 1.0
Sensitivity: 
To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Subject: Re: [fileupload] - aborting file upload
Message-ID: 
 <OF995412B8.EB6E86F7-ON85257228.006ACA5B-85257228.006B7FAA@desknetinc.com>
From: DJohnson@desknetinc.com
Date: Thu, 16 Nov 2006 14:34:06 -0500
Content-Type: multipart/alternative;
 boundary="=_alternative 006B7F8F85257228_="

--=_alternative 006B7F8F85257228_=
Content-Type: text/plain; charset="US-ASCII"

The HTTP Protocol is the limiting factor here.  Any request or response, 
once started, has to complete before either side can send anything else. 
The only way to stop it sooner is to force the connection closed, 
accomplishing a TCP level RESET, but you also lose the ability to send any 
response whatsoever to the request.


Please respond to "Jakarta Commons Users List" 
<commons-user@jakarta.apache.org>

To:     Jakarta Commons Users List <commons-user@jakarta.apache.org>
cc:      
Subject:        Re: [fileupload] - aborting file upload


Martin Cooper wrote:
> On 11/15/06, Andrew Serff <lists@serff.net> wrote:
>>
>> I have this problem as well.  I would love to hear if there is a a way
>> to cancel the client from sending the form data.  It seems that it has
>> to send the entire form data before it can get a response from the
>> server.  I'm guessing this is just a flaw/feature in the way forms are
>> handled in html land...Anyone else have ideas?
>
>
> AFAIK, this is a container issue. The container just keeps on
> accepting the
> response, and there's no way for FileUpload to tell it to abandon the
> remainder.
>
I've heard arguments for it being container/server/protocol/browser
issues. The fact is there is no way to abort the stream on the receiving
end. I've been told that the browser cannot get a response until the
request is complete and the request will not complete until the file has
been sent. A workaround I've seen is to have a separate process run that
monitors the progress of the upload that can handle the abort.  I don't
have an example on hand, but I can provide one for the original poster
if they contact me.

Paul

> --
> Martin Cooper
>
>
> Andrew
>>
>> Shaun_Curtis@amp.com.au wrote:
>> > Hi,
>> >
>> > I am using commons-fileupload v1.1.1 on Websphere Portal v5.1. My 
file
>> > upload works as expected except when the file size exceeds the
>> specified
>> > maximum size.
>> >
>> > parseRequest() throws a FileUploadException as expected, this
>> exception
>> is
>> > caught and processed appropriately and the code executes 
successfully.
>> > However the web page continues to churn, with the progress indicator
>> > increasing slowly. After 5 minutes the page displays the standard
>> "This
>> > page cannot be displayed" error. And the stacktrace below is 
generated
>> in
>> > the log. Has anyone experienced this or know of a way around it?
>> Thanks
>> > for any advice.
>> >
>> > A fragment of my code:
>> >
>> >             DiskFileItemFactory factory = new DiskFileItemFactory();
>> >
>> >             factory.setSizeThreshold(100*1024);
>> >             factory.setRepository(new File("C:\\temp\\"));
>> >
>> >             PortletFileUpload upload = new 
PortletFileUpload(factory);
>> >             upload.setSizeMax(1024*1024);
>> >
>> >             Iterator itemsIter = upload.parseRequest
>> (request).iterator();
>> >
>> >             while (itemsIter.hasNext())
>> >             {
>> >
>> >                 ....
>> >                 ....
>> >                 ....
>> >         }
>> >
>> >         catch (FileUploadException e)
>> >         {
>> >             System.out.println("**************************** FILE
>> UPLOAD
>> > ERRROR");
>> >         ...
>> >         ...
>> >         ...
>> >             return;
>> >         }
>> >
>> >
>> > [16/11/06 13:31:01:250 EST] 1e290c64 SRTServletReq E SRVE0120E: IO
>> Error
>> > java.net.SocketException: Connection reset
>> >         at java.net.SocketInputStream.read(SocketInputStream.java
>> (Compiled
>> > Code))
>> >         at com.ibm.ws.io.Stream.read(Stream.java(Compiled Code))
>> >         at com.ibm.ws.io.ReadStream.read(ReadStream.java(Compiled
>> Code))
>> >         at
>> > com.ibm.ws.http.ContentLengthInputStream.read(
>> ContentLengthInputStream.java(Compiled
>> > Code))
>> >         at com.ibm.ws.io.ReadStream.read(ReadStream.java(Compiled
>> Code))
>> >         at
>> > com.ibm.ws.webcontainer.http.HttpConnection.read(HttpConnection.java
>> (Inlined
>> > Compiled Code))
>> >         at
>> > com.ibm.ws.webcontainer.srp.SRPConnection.read(SRPConnection.java
>> (Compiled
>> > Code))
>> >         at
>> > com.ibm.ws.webcontainer.srt.SRTInputStream.read(SRTInputStream.java
>> (Compiled
>> > Code))
>> >         at
>> > com.ibm.ws.webcontainer.srt.http.HttpInputStream.read(
>> HttpInputStream.java(Compiled
>> > Code))
>> >         at java.io.InputStream.read(InputStream.java(Inlined Compiled
>> > Code))
>> >         at
>> > com.ibm.ws.webcontainer.srt.SRTServletRequest.finish(
>> SRTServletRequest.java(Compiled
>> > Code))
>> >         at
>> > com.ibm.ws.webcontainer.srt.SRTConnectionContext.finishConnection(
>> SRTConnectionContext.java:86)
>> >         at
>> > 
com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java
>> :204)
>> >         at
>> > com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(
>> WebAppInvoker.java:286)
>> >         at
>> >
>> 
com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation
>>
>> (CachedInvocation.java:71)
>> >         at
>> > com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(
>> ServletRequestProcessor.java:182)
>> >         at
>> > com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(
>> OSEListener.java:334)
>> >         at
>> > com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(
>> HttpConnection.java:56)
>> >         at
>> >
>> com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java
>> :624)
>> >         at 
com.ibm.ws.http.HttpConnection.run(HttpConnection.java:448)
>> >         at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java
>> (Compiled
>> > Code))
>> > This email message and any accompanying attachments may contain
>> > information that is confidential and is subject to legal privilege. 
If
>> you are not
>> > the intended recipient, do not read, use, disseminate, distribute or
>> copy this
>> > message or attachments. If you have received this message in error,
>> please
>> > notify the sender immediately and delete this message. Any views
>> expressed
>> > in this message are those of the individual sender, except where the
>> sender
>> > expressly, and with authority, states them to be the views of AMP.
>> Before
>> > opening any attachments, please check them for viruses and defects.
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


--=_alternative 006B7F8F85257228_=--