You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by Sh...@amp.com.au on 2006/11/16 03:42:04 UTC
[fileupload] - aborting file upload
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.
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
Re: [fileupload] - aborting file upload
Posted by Salman Khattak <kh...@yahoo.com>.
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 DJ...@desknetinc.com.
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
Re: [fileupload] - aborting file upload
Posted by Paul J DeCoursey <pa...@decoursey.net>.
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
Re: [fileupload] - aborting file upload
Posted by Martin Cooper <ma...@apache.org>.
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.
--
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
>
>
Re: [fileupload] - aborting file upload
Posted by Andrew Serff <li...@serff.net>.
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
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