You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Bernd Eckenfels (JIRA)" <ji...@apache.org> on 2014/11/21 21:48:33 UTC
[jira] [Comment Edited] (FILEUPLOAD-262) Processing of
multipart/form-data request failed. null
[ https://issues.apache.org/jira/browse/FILEUPLOAD-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221406#comment-14221406 ]
Bernd Eckenfels edited comment on FILEUPLOAD-262 at 11/21/14 8:47 PM:
----------------------------------------------------------------------
The `org.eclipse.jetty.io.EofException: null` Looks like the "null" is a red herring, and this is actually an aborted upload or a zero-byte (maybe even Get?) body?
was (Author: b.eckenfels):
Looks like the "null" is a red herring, and this is actually an aborted upload or a null-byte body?
> 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)