Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.3, 4.0, EE-4.0.0.GA, EE-3.3.0.GA_P03
-
Fix Version/s: EE-4.1.0.RC1, EE-4.1.0.GA, EE-3.3.0.GA_P04, 4.2.BETA, 4.2
-
Component/s: ACE-Components
-
Labels:None
-
Environment:Servlet 3.0
-
Assignee Priority:P2
-
Support Case References:Support Case #13600 - https://icesoft.my.salesforce.com/5007000001SBixn
-
Workaround Exists:Yes
-
Workaround Description:Comment out 'max-file-size' and 'max-request-size' tags in <multipart-config> setting in the web.xml and use ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes instead.
Description
This can be reproduced with the Showcase demo. The web.xml needs to be updated to use the <multipart-config> settings.
Error stack trace:
04-Nov-2015 10:48:46.069 WARNING [http-nio-8084-exec-5] org.icefaces.ace.component.fileentry.FileEntryUpload.afterPhase Problem reading multi-part form upload, likely due to a file upload being cut off from the client losing their network connection or closing their browser tab or window.
java.lang.IllegalStateException: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (151940648) exceeds the configured maximum (52428800)
at org.apache.catalina.connector.Request.parseParts(Request.java:2707)
at org.apache.catalina.connector.Request.parseParameters(Request.java:2951)
at org.apache.catalina.connector.Request.getParameter(Request.java:1091)
at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:380)
at org.netbeans.modules.web.monitor.server.MonitorRequestWrapper.getParameter(MonitorRequestWrapper.java:199)
at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:145)
at org.icefaces.util.ClientDescriptor.getInstance(ClientDescriptor.java:73)
at org.icefaces.impl.application.ClientDescriptorSetup.isSessionAwareResourceRequest(ClientDescriptorSetup.java:38)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.isResourceRequest(SessionAwareResourceHandlerWrapper.java:32)
at org.icefaces.impl.application.SessionTimeoutMonitor.isSessionAwareResourceRequest(SessionTimeoutMonitor.java:41)
at org.icefaces.impl.application.SessionAwareResourceHandlerWrapper.isResourceRequest(SessionAwareResourceHandlerWrapper.java:32)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at org.icefaces.impl.util.CharacterEncodingHandler.isResourceRequest(CharacterEncodingHandler.java:73)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:166)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:642)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:136)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:526)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1078)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:655)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because its size (151940648) exceeds the configured maximum (52428800)
at org.apache.tomcat.util.http.fileupload.FileUploadBase$FileItemIteratorImpl.<init>(FileUploadBase.java:811)
at org.apache.tomcat.util.http.fileupload.FileUploadBase.getItemIterator(FileUploadBase.java:256)
at org.apache.tomcat.util.http.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:280)
at org.apache.catalina.connector.Request.parseParts(Request.java:2640)
... 44 more
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The issue will not occur when the application was started right after the application server was started. Also window scope needs to not be activated by a window scoped bean or org.icefaces.lazyWindowScope=false context parameter.
The fix will register the pushID with the upload progress group in case window scope is not enabled for the application. When window scope si disabled a window scope map is reused for all windows. Before the fix the pushID corresponding to the file entry was kept around in the same window scope map (saved in the session) which caused the component to skip its registration with ICEpush.
No, there's no need for org.icefaces.lazyWindowScope=false. I will run the test again.
The FileUploadBase$SizeLimitExceededException is thrown when servlet container will detect that the upload is larger than the limits defined in <multipart-config> web.xml tag. Unfortunately the servlet container will abort the response right away thus blocking any chance of responding with a partial update that could show the error message.
To work around this issue an asynchronous update could be triggered which should show the message. But FileEntryUpload.afterPhase method is called multiple times for a multipart request which hiders any chance of showing a message that will persist on the page.
Eventually this issue could be fixed but the gains are so minimal that is not worth increasing the complexity of this component. File upload limits can be easily defined in file entry's attributes and uploading a file passed the size threshold will have the validation/error messages rendered as expected.
Documented the workaround as a Known Issue in http://www.icesoft.org/wiki/display/ICE/FileEntry
Tested workaround with attached test case on ICEfaces4 trunk r48469, IE11, FF41, Chrome48: the workaround only works if the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes are used, and the <multipart-config> tag is removed from the web.xml.
Using also the <multipart-config> entries with a greater max file size value than the one specified by the ace:fileEntry's 'maxFileSize' attribute, as recommended in the wiki documentation for ace:fileEntry, still triggers the server error from the description of this JIRA.
I updated the Wiki page to clarify that the multipart-config entries cannot be used if the ace:fileEntry component error message is desired.
There is an issue with the workaround, in that ace:fileEntry will not function on certain servers without the <multipart-config><max-file-size> web.xml entry.
Showcase > fileEntry demos pass on WAS 8.5.5.4 when using the showcase <multipart-config> default entries.
File uploads don't seem to work on any of the showcase demos on WAS 8.5.5.4, when using below configuration with the <max-file-size> entry disabled in <multipart-config>; this configuration works only on Tomcat7, displaying a validation "Submitted file is too large" message, when the file has the size above the value set in the ace:fileEntry's 'maxFileSize' attribute on the page.
<multipart-config>
<!-max-file-size>52428800</max-file-size->
<max-request-size>52428800</max-request-size>
<file-size-threshold>0</file-size-threshold>
</multipart-config>Regards,
Carmen
Carmen, can you please retest file upload in showcase but make sure that both max-file-size and max-request-size are commented out? If that won't work increase both max-file-size and max-request-size to a value higher than the one defined in file entry's _ maxFileSize_ attribute.
Tested with with Jenkins IF4 trunk Build# 1842, with showcase > fileEntry > Overview demo:
If commenting out both <max-file-size> and <max-request-size>, the behavior is the same on WAS 8.5.5.4, as if disabling only the <max-file-size>, with the default values for the fileEntry's maxFileSize, as specified on Fileentry.xhtml (maxFileSize="6291456"). Trying to upload a larger file is not allowed, but there is no message rendered on page.
If using the same .war file on Tomcat7, the "Submitted file is too large" validation message is rendered.
If using the default showcase on WAS 8.5.5.4 (this has both max-file-size and max-request-size with higher values than the one defined in the fileEntry's maxFileSize), the fileEntry > Overview demo rendered the "Submitted file is too large" validation message when trying to upload a larger file.
Okay, that is the expected behaviour on WS 8.
I've edited the ace:fileEntry Wiki page entry for this as follows:
Note that when using the Servlet 3 <max-file-size> and <max-request-size> tags in the <multipart-config> settings in the web.xml with ace:fileEntry no error messages will be displayed by the component if an upload attempt is made with a file that is too large. If a component error message is desired it is necessary to also specify the ace:fileEntry's 'maxFileSize' and 'maxFileSizeMessage' attributes with values that are less than (smaller) than those specified in the <multipart-config> entries in the web.xml.
Attached test case that shows this issue.
Steps: