You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Salman Khattak <kh...@yahoo.com> on 2007/01/11 23:16:52 UTC

Re: [fileupload] - aborting file upload

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" 
> <co...@jakarta.apache.org>
> 
> To:     Jakarta Commons Users List <co...@jakarta.apache.org>
> cc:      
> Subject:        Re: [fileupload] - aborting file upload
> 
> 
> Martin Cooper wrote:
>> On 11/15/06, Andrew Serff <li...@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


Re: [fileupload] - aborting file upload

Posted by Salman Khattak <kh...@yahoo.com>.
David,
Here are some links I researched to do fileupload monitoring.
http://del.icio.us/khattak/fileupload

The status jsp has the following code snippet:
<c:if test="${sessionScope.FILE_UPLOAD_STATS.currentStatus == 'error'}">
	<div id="abortdiv" onclick="javascript:refresh();" style="background-color:
red; width: 450px; height: 20px; text-align: center; cursor: pointer">
		ERROR!<br/>CLICK HERE TO ABORT UPLOAD
	</div>
</c:if>

The 'parent' page is monitoring the upload in a 'status' div - the contents
of which are generated by the status jsp - relevant parent page snippet:

  var updater = null;
  function startStatusCheck()  {
    updater = new Ajax.PeriodicalUpdater(
                               
'status','${pageContext.request.contextPath}/UploadStatus.do',
                                {asynchronous:true, frequency:1, method:
'get', parameters: 'c=status', onFailure: reportError, decay: 2});
    return true;
  }


The refresh function is in the parent page and is as follows:
  function refresh() {
	window.location.reload();
  }

All this will make more sense if you go through the file upload monitoring
solutions found in the links I have posted above. This using Prototype Ajax.

HTH

Salman Khattak


david2 wrote:
> 
> Salman,
> 
> But what Jakarta Commons HttpClient API do you invoke to abort the upload
> and force the connection to close?
> 
> -David
> 
> 

-- 
View this message in context: http://www.nabble.com/-fileupload----aborting-file-upload-tf2640397.html#a10380758
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


Re: [fileupload] - aborting file upload

Posted by david2 <Da...@l-3comcept.com>.
Salman,

But what Jakarta Commons HttpClient API do you invoke to abort the upload
and force the connection to close?

-David

-- 
View this message in context: http://www.nabble.com/-fileupload----aborting-file-upload-tf2640397.html#a10380029
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


Re: [fileupload] - aborting file upload

Posted by Salman Khattak <kh...@yahoo.com>.
As mentioned in the thread, only the client/user agent (browser) can abort
the upload. I am using Ajax to monitor the upload and when I feel the upload
is not going to be successful (my own criteria) I display a upload error
message with a link to another page. Like so  someurl Please abort upload 
so that the user can 'move' away from the  upload. Not very elegant, but the
only hack i could think of. HTH. Salman Khattak

david2 wrote:
> 
> How does one go about "forcing" the connection closed from the Client
> side?  I am running into problems with connections not being close when
> used by Axis, but can't find a way to trigger
> HttpMethodBase.setConnectionCloseForced (a protected method) from being
> sent.  Any ideas?
> 
> Thanks,
> -David
> 
>> 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.
> 
> 

-- 
View this message in context: http://www.nabble.com/-fileupload----aborting-file-upload-tf2640397.html#a10378254
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


Re: [fileupload] - aborting file upload

Posted by david2 <Da...@l-3comcept.com>.
How does one go about "forcing" the connection closed from the Client side? 
I am running into problems with connections not being close when used by
Axis, but can't find a way to trigger
HttpMethodBase.setConnectionCloseForced (a protected method) from being
sent.  Any ideas?

Thanks,
-David

> 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.

-- 
View this message in context: http://www.nabble.com/-fileupload----aborting-file-upload-tf2640397.html#a10377631
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