[fileupload] - aborting file upload

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[fileupload] - aborting file upload

Shaun_Curtis
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.
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

serff
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?

Andrew

[hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

Martin Cooper-3
On 11/15/06, Andrew Serff <[hidden email]> 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.

--
Martin Cooper


Andrew

>
> [hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

Paul deCoursey
Martin Cooper wrote:

> On 11/15/06, Andrew Serff <[hidden email]> 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
>>
>> [hidden email] 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

DJohnson-2
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"
<[hidden email]>

To:     Jakarta Commons Users List <[hidden email]>
cc:      
Subject:        Re: [fileupload] - aborting file upload


Martin Cooper wrote:

> On 11/15/06, Andrew Serff <[hidden email]> 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
>>
>> [hidden email] 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

Salman Khattak
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


Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

david2
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.
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

Salman Khattak
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 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.
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

david2
Salman,

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

-David
Reply | Threaded
Open this post in threaded view
|

Re: [fileupload] - aborting file upload

Salman Khattak
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