commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salman Khattak <khatta...@yahoo.com>
Subject Re: [fileupload] - aborting file upload
Date Thu, 11 Jan 2007 22:16:52 GMT

I have noticed if user-agent is in the middle of file upload and the user
does a refresh (F5) the transmission is aborted. The server craps out with
unexpected end of stream. This has lead me to an idea.
I am using an Ajax Updater to monitor file upload. And my extended code sets
the currentstatus on the filuploadlistener to 'error'. May be somehow we can
force a refresh on the user-agent via javascript/ajax. Just a thought.
Salman Khattak

DJohnson wrote:
> 
> 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
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-fileupload----aborting-file-upload-tf2640397.html#a8286934
Sent from the Commons - User mailing list archive at Nabble.com.


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


Mime
View raw message