-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 4/25/19 15:55, Mark Thomas wrote: > On 23/04/2019 16:29, Olivier Jaquemet wrote: >> On 23/04/2019 16:12, Christopher Schultz wrote: >>> On 4/23/19 05:58, Olivier Jaquemet wrote: > > <snip/> > >>>> * Add the following directive to context.xml : <Resources >>>> cachingAllowed="false" /> >>> Okay. Why context.xml, by the way? >> I don't even know (yet...) why this setting was added in the >> first place in the environment where it was present... ! so why >> this file... I don't know either :) > > DefaultServlet is assuming caching is in place. If you disable it, > you hit this issue. > >>>> * Create a large file in the samples webapp, for example : >>>> cd webapps/examples dd if=/dev/zero of=large.txt bs=1k >>>> count=2000000 > > <snip/> > >>> Reading the code for FileResource.getContent, it's clear that >>> the entire file is being loaded into memory, which obviously >>> isn't going to work, here. I'm wondering why that's happening >>> since streaming is the correct behavior when caching=false. >>> Also strange is that DefaultServlet will attempt to call >>> FileResource.getContent() -- which returns a byte[] -- and, if >>> that returns null, it will call FileResource.getInputStream >>> which ... calls this.getContent. So this looks like a >>> special-case for FileResource just trying to implement that >>> interface in the simplest way possible. > > It is assuming it is working with a CachedResource instance rather > than directly with a FileResource instance. > >>> FileResource seems to implement in-memory caching whether it's >>> enabled or not. >>> >>> I can't understand why this doesn't fail for the other kind of >>> connector. Everything else is the same? You have two separate >>> connectors in one instance, or are you changing the connector >>> between tests? >> >> Everything is exactly the same as I have only one instance with >> two separate connectors (AJP+HTTP). > > I suspect HTTP avoids it because sendfile is enabled. > > The DefaultServlet logic needs a little refactoring. And maybe FileResource, too? I wasn't able to follow the logic of whether caching or not caching was enabled. I only did cursory checking, but it seemed like none of the resources implementations included any caching-aware code at all. Was I looking in the wrong place? If the resources are caching-aware, then I think the DefaultServlet can just always use Resource.getInputStream. Hmm. That might cause a lot of unnecessary IO if the bytes are actually available. Maybe when caching is disabled, we need to wrap resources in an UncachedResource object which always returns null from getContent() and forces the use of an InputStream? - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlzCFbkACgkQHPApP6U8 pFjfng//YwlhPYoJLxXA1QOr9wQ3QvXusXqoqExQ7cQVlv9Z+in7Xl4/qHp65QBp wlAGqxGCvxbltQCiBuMmIoK3Lz8GEJcgAl+Rt7FCDPC22yfJ/dCQjFEgAQ8+BftD VohdH+7fJxP+KF2P29qh3Yb041VDC6L1NkkERUOf+4mDKA/B0RnmhuW/QVRCpB5a 6Ola0yR8VP6zfjubA+PkUjDtXD4nw0vIQ5MbvV3pqIIPE5bA0+GfgbslTbgNiPNZ u8tQlHJzUuvEUexzWCN9f6Ltu0pO8l1ovp4djP5CMLuY1PUm/ZUIkJw1wuB8Qft4 ByX/i5VzOPXxzbfw2cSboNe5PKhHk1LOokLNWB0UDfPsHWJI9Ef0G0mr5neljUGY uu9tAFG/G6G1LkglLRNVlBajmXi3wMy9I73l2Pkj7lE45kRwv+z185IobG/6034x ocX8u8UMNAmi4dWSc51x4PaXYTaI7lH9jmrPsyYDq0AHhrd5RxVT1Q9KT2sJexY2 6Qf/6mOXqzUf6H5aBrloOiVOcMOrtYRJG5mRK+UuoaaN+zngvubhlQIVHOa+8eP/ kDtKsQctLoLafvVWpTRsy7wMpOcfD2LkyDDhVI9QpwJtigQwvjuqGRUc+iITvejX +tIoaqqwoHb0MoHPHdQI+0XStCxEa6N5oK3EtbjhwKpAaZnsuiU= =drNE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
