[ 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)