You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Gerald Turner (JIRA)" <ji...@apache.org> on 2006/05/17 18:42:06 UTC

[jira] Commented: (FILEUPLOAD-106) parseRequest randomly throws Stream ended unexpectedly

    [ http://issues.apache.org/jira/browse/FILEUPLOAD-106?page=comments#action_12412207 ] 

Gerald Turner commented on FILEUPLOAD-106:
------------------------------------------

User error!

The client was running two threads sharing instances of HttpClient FilePart[] while uploading to two FileUpload servlet servers.  Changed it so each upload thread instantiates it's own FilePart[] and the error no longer randomly occurs.

Please close the bug.

> parseRequest randomly throws Stream ended unexpectedly
> ------------------------------------------------------
>
>          Key: FILEUPLOAD-106
>          URL: http://issues.apache.org/jira/browse/FILEUPLOAD-106
>      Project: Commons FileUpload
>         Type: Bug

>     Versions: Nightly Builds
>  Environment: The client and server environments are all Solaris 9, Java 1.4.2_05, JBoss
> 3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
> a few LANs with very low latency (2ms).
>     Reporter: Gerald Turner
>  Attachments: commons-fileupload-1.2-SNAPSHOT-initCause.patch
>
> Hello, I have an application using FileUpload which intermittently encounters
> this error as well, about once every 100 uploads.  It's a simple servlet that
> writes posted files to disk.  The client application that is posting to this
> FileUpload servlet is using Jakarta Commons HttpClient 3.0.1 with features such
> as MultipartRequestEntity and MultiThreadedHttpConnectionManager.
> Typically the posts contain two to three FileParts, a few 20KB audio/x-wav
> files accompanied by a 15KB application/voicexml+xml file.
> The servlet is actually running on two different servers, and the single client
> posts to both of them, this occasional "Stream ended unexpectedly" error will
> occur on one server and still succeed on the other.
> The client and server environments are all Solaris 9, Java 1.4.2_05, JBoss
> 3.2.5 running Tomcat 5.0.26 using the default 8080 connector, and separated by
> a few LANs with very low latency (2ms).
> It's interesting to note that the FileUpload servlet catches the "Stream ended
> unexpectedly" exception during parseRequest and is still able to
> HttpServletResponse.send(500, e.getMessage()), which the client receives and
> there are no other errors leading me to indicating the socket connection was
> ganked.
> I've applied a patch to the latest FileUpload 1.2-SNAPSHOT in SVN for including
> the root cause in exceptions, e.g.:
> +++ src/java/org/apache/commons/fileupload/FileUploadBase.java
> @@ -381,9 +381,9 @@
>            } catch (IOException e) {
> -            throw new FileUploadException(
> -                "Processing of " + MULTIPART_FORM_DATA
> -                    + " request failed. " + e.getMessage());
> +            throw (FileUploadException) new FileUploadException(
> +                "Processing of " + MULTIPART_FORM_DATA
> +                    + " request failed. " + e.getMessage()).initCause(e);
>          }
> Here is a stacktrace of one of the random "Stream ended unexpectedly"
> exceptions:
> 2006-05-16 16:59:03,947 ERROR [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Failed to parse uploads from request: Processing of multipart/form-data request failed. Stream ended unexpectedly
> org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly
>         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
>         at com.xo.nextgen.fileupload.FileUploadServlet.doPost(FileUploadServlet.java:278)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:275)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)        at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly
>         at org.apache.commons.fileupload.MultipartStream.readBodyData(MultipartStream.java:540)
>         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
>         ... 31 more
> The other server happily accepted the same upload:
> 2006-05-16 16:59:03,929 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Received file /NTI/9992/voice/test/Voice/4vg85qUY.wav (size=25182)
> 2006-05-16 16:59:03,932 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Wrote file /web/voiceweb/htdocs/NTI/9992/voice/test/Voice/4vg85qUY.wav
> 2006-05-16 16:59:03,933 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Received file /NTI/9992/voice/test/Voice/8AyWrP3j.wav (size=37168)
> 2006-05-16 16:59:03,936 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Wrote file /web/voiceweb/htdocs/NTI/9992/voice/test/Voice/8AyWrP3j.wav
> 2006-05-16 16:59:03,937 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Received file /NTI/9992/xml/JUnit-4ubjoyNf-0.vxml (size=11120)
> 2006-05-16 16:59:03,939 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Wrote file /web/voiceweb/htdocs/NTI/9992/xml/JUnit-4ubjoyNf-0.vxml
> 2006-05-16 16:59:03,940 DEBUG [com.xo.nextgen.fileupload.FileUploadServlet] doPost: Stored 3 files from 3 request content parts in 0:00:00.135

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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