Thanks Mark cjb> Anyone have advice on, experience with, or cjb> info about setting cachingAllowed=false? cjb> [...] cjb> In our testing of TC 8.5.32 on Java 8u181, cjb> report output Excel files won't load cjb> (immediately). An error is displayed to cjb> the user. These Stack Overflow topics cjb> below point to a cachingAllowed setting cjb> [...] cjb> I added <Resources cachingAllowed="false" /> cjb> to the <Context> in TC/conf/context.xml, cjb> which solved the problem.
cjb> 1. What are the ramifications of disabling cjb> the cache? IOW, what are the potential cjb> side-effects? mt> The cache keeps the contents of static files mt> in memory to improve performance. In theory mt> - the more of your requests that can be served mt> from memory, the faster the response time. The mt> side effect is a slower response time. How mt> much actual difference this feature makes will mt> depend on how much static content there is in mt> your app, how frequently it is requested and mt> how frequently it is changed. Yeah, I was thinking something vaguely along those lines. cjb> 2. Is there a "better" way to specify the setting? mt> Maybe. The change you made applied that setting mt> to ALL web applications in that Tomcat instance. mt> If you only wanted to apply it to "/foo" then mt> you would create: mt> $CATALINA_BASE/conf/<engine-name/<host-name>/foo.xml mt> [...] OK, good to know, thanks. cjb> 3. Is there a "better" way to solve the problem? mt> For a given value of "better"... :-) mt> What is happening is that: mt> - "something 1" requests the file mt> - the file is not found and the cache records this mt> - "something 2" creates the file mt> - "something 3" requests the newly created file mt> - the cache is still valid so the not found' response is returned mt> - time passes, 'not found' cache response expires mt> - "something 4" requests the newly created file which is now returned mt> [...] mt> What you'd need to figure out is what is "something 1" mt> and what triggers it before "something 2". With that mt> information, you should be able to refactor the app so mt> "something 1" doesn't happen or happens after "something 2". 1. User client browser sents report request to TC. 2. Servlet does some stuff and calls Apache POI to generate the Excel file. 3. Servlet sends rendered JSP response, which contains HTML and Javascript. 4. Client browser processes response with Javascript, which opens a new window with the URL of the generated Excel file. 5. User client browser sends request for the generated Excel file from the new window. 6. Tomcat returns 404 not found response to new window. 7. User waits 5 to 10 seconds and clicks reload in the browser new window. 8. New client browser window sends request for the generated Excel file to TC. 9. Tomcat returns Excel file to client new window. 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? 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?) 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. cjb> a. This is a low-volume application. cjb> Little traffic and few users. cjb> cjb> b. Seeing as we're addressing production, cjb> we would like to implement a rapid solution. cjb> Don't want to refactor the application, cjb> which would take more time. mt> Given the caveats, you solution looks to be the best (assuming performance is acceptable). Thanks Mark. It's reassuring to know the work-around is functional and not unreasonable. -- Cris Berneburg CACI Lead Software Engineer
