On 09/12/2013 21:40, Konstantin Preißer wrote: > With Tomcat 8.0.0-RC6, I seem to have problems serving large static > files in one of my webapps. > > I've run it on a Windows Server 2012 R2 system with Java 1.7.0_45 > (64-Bit) and the NIO HTTP connector. The webapp contains a large > static file with a size of 4,582,875,812 bytes. > > When I try to download that file in the browser, I get the following > exception: > > 09-Dec-2013 22:21:22.511 SEVERE [http-nio-8006-exec-2] > org.apache.catalina.core.StandardWrapperValve.invoke > Servlet.service() for servlet [default] in context with path [] threw > exception java.lang.ArrayIndexOutOfBoundsException: Unable to return > [/temp/file.bin] as a byte array since the resource is > [4,582,875,812] bytes in size which is larger than the maximum size > of a byte array
<snip/> > However, I am unable to reproduce this exception when placing the > file in Tomcat's default ROOT webapp. I suspect that the filters > could have some effect. I think I did not get such errors with the > same webapp and Tomcat 7.0.42. I have not yet tested other Tomcat > versions. The "XUaCompatibleHeaderFilter" in the stacktrace just > appends an "X-UA-Compatible: IE=Edge" header to the response, then > invokes chain.doFilter(request, response). The Tuckey > UrlRewriteFilter is configured to rewrite some URLs that start with a > capital letter (but not the URL which requests the static file). > > Any idea what is going on there? Why would Tomcat create such a big > byte array for a static file? Lots of things going on here. 1. The content of resources was still being cached on access even if it was bigger than the maximum object size. 2. The test of object size was checking against the total limit for the cache rather than the single object limit. 3. The DefaultServlet was working on assumptions that were true in the 7.0.x resources implementation but not true in the new 8.0.x implementation. All of the above - and few additional issues spotted along the way - have been fixed in trunk. Thanks for the report. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
