commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Rink (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FILEUPLOAD-262) Processing of multipart/form-data request failed. null
Date Mon, 24 Nov 2014 07:27:12 GMT

    [ https://issues.apache.org/jira/browse/FILEUPLOAD-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222744#comment-14222744
] 

Kristian Rink commented on FILEUPLOAD-262:
------------------------------------------

Though I also thought this, I am unsure here. Part of our customers us a JUpload based Java
applet for uploading files in batch operation, and, watching one of them via TeamViewer, it
seems while uploading (n) files, the upload always will transmit all(?) data and then just
fail after. I attached part of the applet debug log below. The length of data reported here
(getUploadLength()) on the client does match what the server seems to see. I've also raised
this question on a Jetty mailing list as I am unsure who's really to blame here. Maybe additional
yet empty form fields in the multipart/form-data upload? 

All along with this: I traced through the commons-fileupload sources and had a look at FileUploadBase#parseRequest(...)
and wonder whether this method could or should be modified to not necessarily throw an Exception
but rather to return files that have successfully been transmitted all along with an error
message that something was wrong. In my test case, I tried uploading roughly 250 PDF files,
each of them some megabytes in size. If this request fails, maybe 220 of 250 files have been
correctly transmitted, yet all of them get wiped at the end of parseUploadRequest() in case
of !successful ... 


{code}
00277 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	-----------------------------ec5489tafxl\r\n
00277 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	Content-Disposition: form-data; name="File0";
filename="...........pdf"\r\n
00277 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	Content-Type: application/acad\r\n
00277 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	\r\n
00278 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	--- fileheader end
00279 	16:12:01.705 	FileUploadThreadHTTP	[DEBUG] 	in UploadFileData.uploadFile (amount:5421811,
getUploadLength(): 5421811)
00280 	16:14:28.421 	FileUploadThreadHTTP	[ERROR] 	[wjhk.jupload2.exception.JUploadIOException:javax.net.ssl.SSLException]
Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection
reset by peer: socket write error (Upload-Vorgang wegen eines Fehlers gestoppt)
00281 	16:14:28.421 	FileUploadThreadHTTP	 	wjhk.jupload2.exception.JUploadIOException: javax.net.ssl.SSLException:
Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection
reset by peer: socket write error
00281 	16:14:28.421 	FileUploadThreadHTTP	 		at wjhk.jupload2.upload.helper.HTTPConnectionHelper.dispose(HTTPConnectionHelper.java:410)
00281 	16:14:28.421 	FileUploadThreadHTTP	 		at wjhk.jupload2.upload.FileUploadThreadHTTP.cleanRequest(FileUploadThreadHTTP.java:160)
00281 	16:14:28.421 	FileUploadThreadHTTP	 		at wjhk.jupload2.upload.DefaultFileUploadThread.doNonChunkedUpload(DefaultFileUploadThread.java:716)
00281 	16:14:28.421 	FileUploadThreadHTTP	 		at wjhk.jupload2.upload.DefaultFileUploadThread.doUpload(DefaultFileUploadThread.java:510)
00281 	16:14:28.421 	FileUploadThreadHTTP	 		at wjhk.jupload2.upload.DefaultFileUploadThread.run(DefaultFileUploadThread.java:331)
00281 	16:14:28.421 	FileUploadThreadHTTP	 	Caused by: javax.net.ssl.SSLException: Connection
has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
by peer: socket write error
{code}

> Processing of multipart/form-data request failed. null
> ------------------------------------------------------
>
>                 Key: FILEUPLOAD-262
>                 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-262
>             Project: Commons FileUpload
>          Issue Type: Bug
>    Affects Versions: 1.2, 1.3.1
>         Environment: Application: Jetty 9.1.4, Debian stable x86_64, Java 1.7.0_51 
> Public access through reverse proxy (apache 2 2.2.22 + mod_proxy)
>            Reporter: Kristian Rink
>            Priority: Minor
>              Labels: eof, exception, stacktrace
>
> Exposing an upload feature in an existing web application, I frequently see stack traces
as the one posted below in my server log files. Additional notes:
> - The application runs in an embedded jetty (HTTP) behind an apache2
> mod_proxy reverse proxy (HTTPS).
> - These issues do not generally appear, I tried quite some uploading
> myself today and never managed to reproduce this behaviour even while
> uploading loads of files, large files and both together.
> - It does not seem to be generally tied to a particular browser; the
> users associated with these messages use Firefox, MSIE or Chrome.
> - Looking at network traffic (and the transfer monitor in the app), it
> _seems_ all data to be sent with the request have successfully been
> transmitted yet parsing the request, ultimately, fails.
> - On _some_ clients, in such situations users reported the upload was
> canceled with a "connection reset by peer" error, even though I do not
> see reasons for that in our mod_proxy server log.
> - The application uses the approach outlined in [1] to render a progress bar based upon
JavaScript and DWR. There is code in that controller trying to check how much data has been
received by the server so far. I do dump these information to the log right now, and it seems
all(?) data has been received before we run into this error, even though I am not sure about
that at all as I am unsure how the frameworks handles HTTP traffic internally and how this
is handled in example with chunked transfer encoding:
> 2014-11-21 18:26:01,846 [qtp1780643722-438] INFO WebUIUploadController - uploadStats:
2100399 of 2100399
> Stack trace seen in such situations:
> {code:java}
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data
request failed. null
>         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)
~[commons-fileupload-1.3.1.jar:1.3.1]
>         at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115)
~[commons-fileupload-1.3.1.jar:1.3.1]
>         at de.pc.frontend.WebUIUploadController.submitUpload(WebUIUploadController.java:189)
~[webprojekt-1.2-SNAPSHOT.jar:na]
>         at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) ~[na:na]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.7.0_51]
>         at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_51]
>         at org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
[spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:669)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:585)
[spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [javax.servlet-api-3.1.0.jar:3.1.0]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javax.servlet-api-3.1.0.jar:3.1.0]
>         at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:738) [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1651)
[jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
[spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
[spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1639)
[jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
[spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
[spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
>         at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
[jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
[jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:568)
[jetty-security-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1111)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:478)
[jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.Server.handle(Server.java:462) [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:279) [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:232)
[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
[jetty-io-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
[jetty-util-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
[jetty-util-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> Caused by: org.eclipse.jetty.io.EofException: null
>         at org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:465) ~[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:125) ~[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
>         at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:999)
~[commons-fileupload-1.3.1.jar:1.3.1]
>         at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)
~[commons-fileupload-1.3.1.jar:1.3.1]
>         at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_51]
>         at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100) ~[commons-fileupload-1.3.1.jar:1.3.1]
>         at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70) ~[commons-fileupload-1.3.1.jar:1.3.1]
>         at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:347)
~[commons-fileupload-1.3.1.jar:1.3.1]
>         ... 39 common frames omitted
> {code}
> There is Spring in there but the problem seems unrelated. It happens just alike using
fileupload 1.2 and 1.3.1. I have seen similar issues before using the same application in
Sun/Oracle Glassfish, too. Playing with the configuration of the reverse proxy in front (especially
talking keepalive, chunked vs. non-chunked transfers, timeouts, ...) doesn't seem to change
much. 
> Seen this pretty often so far, yet have no reliable way of reproducing it. Feel free
to ask for more information, not sure how useful this is so far.
> [1]http://jtechnoprojects.blogspot.de/p/ajax-file-upload-with-progress-bar.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message