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] [Created] (FILEUPLOAD-262) Processing of multipart/form-data request failed. null
Date Fri, 21 Nov 2014 20:11:33 GMT
Kristian Rink created FILEUPLOAD-262:
----------------------------------------

             Summary: 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.3.1, 1.2
         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


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