On 04/10/18 20:29, Berneburg, Cris J. - US wrote:
> RAMBLE: The thing is, it worked in TC 6.0 but not 8.5.  Is it possible a 
> major change in TC threading occurred, so the servlet returns the JSP 
> response before the Excel file is finished being generated by POI?  No, 
> that's not it - turning off caching fixes the problem.  Did TC 6.0 not cache 
> files?

The resources implementation was completely re-written for 8.x in
anticipation of a new specification feature that never materialised.
Despite that, it needed to be done as there were a number of
over-lapping solutions that were very fragile where they overlapped.

I'm fairly sure not found results weren't cached in 6.0.x.

> GENERAL: Does the fact that a file does *not* exist need to be cached?  If a 
> cache ping fails, checking the file system immediately would make new files 
> available immediately too, instead of after the cache expires.  (Conversely, 
> how does it handle a file deleted from the file system still existing in the 
> cache?)

Caching not found can improve performance.
If a file is deleted, that deletion won't be detected until the
associated cache entry expires.

> SPECIFIC: The Excel files are dynamic, one-time reports, accessed only once.  
> They don't need to be cached.  Is it possible to declare only the Excel 
> reports output folder as non-cache-able but leave the (default) context cache 
> setting as-is so everything else can be cached in the default way?  That is, 
> set up the Excel report output folder as a separate "resource" with an 
> independent cache setting?  Right now the Excel folder is embedded in the app 
> file system: TC/webapps/app/excel.

At the moment, no. No reason why we couldn't extend the resources
implementation and either add a few more options (based on path and/or
filename and/or mime-type and/or whatever). Where we draw the line
between 'standard' options and what requires a custom CacheSelector
(ideas for better name welcome) is open to debate. Something for an
enhancement request?


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to