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

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: 

cjb> a. This is a low-volume application.
cjb> Little traffic and few users.
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 

Cris Berneburg
CACI Lead Software Engineer

Reply via email to