tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [VOTE] Release Apache Tomcat 8.0.0-RC6
Date Tue, 10 Dec 2013 00:21:57 GMT
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


> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message