Re: TC 8.5 cachingAllowed=false ramifications?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 10/9/18 11:59, Berneburg, Cris J. - US wrote: > Thanks Chris > > cjb> of TC 8.5.32 on Java 8u181, report output Excel cjb> files > won't load (immediately). An error is cjb> displayed to the user. > [...] cjb> 1. What are the ramifications of disabling the cache? > cjb> IOW, what are the potential side-effects? [...] cjb> 2. Is > there a "better" way to specify the setting? [...] cjb> 3. Is there > a "better" way to solve the problem? [...] > > cs> Long ago, we added something similar to what you cs> are > talking about. Basically, it was a file- cs> upload capability for > images. We waffled about cs> whether to just map the > /uploaded-images/ URL cs> space directly to the disk and have > DefaultServlet cs> serve the bytes or to write our own servlet > [...] > > cs> Re-reading the documentation for cs> (specifically, > ), it seems that: cs> cs> > cachingAllowed="false" cs> base="/base/path/to/image/files/" cs> > className="org.apache.catalina.webresources.DirResourceSet" cs> > webAppMount="/uploaded-images/" /> cs> cs> ... might do the trick, > and it would only disable caching for that portion of the disk. > cs> cs> Perhaps this would be a better solution, because cs> it > only disabled caching for a *portion* of the cs> requests you'll be > handling. > > Yes, exactly! I might experiment with something like that "next". > > cjb> Is it possible to declare only the Excel reports cjb> output > folder as non-cache-able but leave the cjb> (default) context cache > setting as-is so everything cjb> else can be cached in the default > way? That is, cjb> set up the Excel report output folder as a > separate cjb> "resource" with an independent cache setting? cjb> > Right now the Excel folder is embedded in the app cjb> file system: > TC/webapps/app/excel. > > Although I wonder if having the Excel folder embedded in the app > content folder and specifying it in a "PostResources" clause at the > same time would somehow conflict with the default servlet already > serving it. Good thought: the DefaultServlet will use the "resources" as set-up by the context, so "post resources" will fall at the end of the list of things to check. If the "excel documents" folder is actually rooted in the web root of the context, then yes, you'll achieve nothing. On the other hand, you shouldn't put your excel files into a directory rooted in the web root of the context because they will be deleted if you undeploy the web application. (oops) Also, using PreResources is a potential security hazard, as "pre resources" are checked for *classes* before the regular WEB-INF/classes and WEB-INF/lib/*.jar files and so it's easy to inject a rogue class into your application if an attacker can arrange for that kind of things to happen. In your use-case, you are building the document internally (so the user isn't uploading files), but it's worth pointing-out that in an upload-situation, use of "pre resources" to serve uploaded files can get you compromised in a hurry. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu+CeUACgkQHPApP6U8 pFi8aA//YhQ5C+aevSfPoYYyooN+M2Kw9PWWhVDkVJs2esOPkSrwNFG7TCHnLn52 cBcgqOSKX6nvlanwyk+3aFlk2OdRrZL2IRqszXuugQr2fZpC18qvHru9xi6JpCDJ kFr+qhp0xQ6WNlG/+DnaOXLg8/x3m0N+iihjNOgxbtvwcag1AksADpRpYnscnen1 bimNvvBatyiSyBUZ3m5FQjF3E3iuB63MXygT3emwWsOrGya7PafoeG9Wbr+nD6dc z4nEp6UOqVk0FSyYgaFDoUYAZIa7PNVaHWs+SCFwm749pSjvg9vgnMBoYsBPN0XH t0jHvSMu5ye5H+sACxgjaY0S/2l78ps1dg9ULlHDJM3zIdqM8TQIMObmUUAk7tUJ LDXf0KJEZa8sLYm9o6PEaUHReLrM8I2WylwW6puTSTvRDDjkcoKUj4Nc8xEsDppb yu79aHG5EiiCJfJ6rdo5OdGRKKHaFa27upxdy4yzr9whzCLG8vqpPUmKGiKHPw9O 9lQ6RVhaGO3NYromew614BaujgJbkIHNYtLNkIzVvAK5EuyiRewLSrIKUaC+R5JO wY41Z37ai6bN4mR2chiqFIyPX871OUYFUWMzIbmKZB8xXugKhhdl3syq4vp+uiIr kgStOuxlaUeMUXWW6q5Tvdq5rUc7mzkkVsixyeqHKqw6zjhtfY0= =TguN -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 8.5 cachingAllowed=false ramifications [and potential Resource CacheSelector specification]?
On 10/9/2018 11:03 AM, Berneburg, Cris J. - US wrote: Mark cjb> SPECIFIC: The Excel files are [...] accessed only cjb> once. They don't need to be cached. Is it cjb> possible to declare only the Excel reports output cjb> folder as non-cache-able but leave the (default) cjb> context cache setting as-is so everything else cjb> can be cached in the default way? That is, set cjb> up the Excel report output folder as a separate cjb> "resource" with an independent cache setting? cjb> Right now the Excel folder is embedded in the app cjb> file system: TC/webapps/app/excel. mt> At the moment, no. No reason why we couldn't extend mt> the resources implementation and either add a few mt> more options (based on path and/or filename and/or mt> mime-type and/or whatever). Where we draw the line mt> between 'standard' options and what requires a mt> custom CacheSelector (ideas for better name welcome) mt> is open to debate. Something for an enhancement request? A bare-minimum approach that might work could be a new Resources attribute "cacheNotFoundResults" (default=true). However... [LONG] Something more robust might meet community needs better, depending on what folks require, rather than a one-off fix. Need to specify what the cache implementation applies to. By folder? By file type? What other folks want? I vote for an implementation by folder. I think that a "url-pattern" would be a good choice. That way we can reuse code and users will not have to learn a new "setting" as it is already a familiar concept. Igal How to implement? Move all caching specifications to a new CacheHandler class that the Resource references. The 8.5 Resources docs list these attributes: allowLinking, cacheMaxSize, cacheObjectMaxSize, cacheTtl, cachingAllowed, className, trackLockedFiles (is tLF cache-related?). The decoupled specs of Resources(a) and Cache(b) would start with: a. Resources: allowLinking, className, trackLockedFiles, cacheMaxSize(D), cacheObjectMaxSize(D), cacheTtl(D), CacheSelector(new). - (D): cacheMaxSize, cacheObjectMaxSize, cacheTtl would be deprecated but remain in existing TC implementations (7, 8, 9) to maintain backwards-compatibility. New versions of TC (10+) would not support those options. - CacheSelector would default to the default cache implementation if not specified. Specifying an empty string "" would equate to "none" (no caching), or maybe a no-op canned class of CacheNone could be selected. b. Cache: cacheMaxSize, cacheObjectMaxSize, cacheTtl, cacheNotFoundResults(new), cachedFolder(new). - We could remove the prefix of "cache" to avoid the Smurf syndrome since it applies to cache anyway. - cachingAllowed would be removed since that would be the Cache implementation class itself. - cachedFolder would default to the app deployment folder. The default cache handler CacheHandlerDefault class manages the cache for the app deploy folder(s) by default without changing the TC config. You could specify a canned or custom cache handler at any depth for a different cache implementation for a specific folder set that would override the default. That is, a bunch of folders would have the default cache handler by default, but a special (sub)folder could have a different cache implementation. Questions / Observations: - How to specify different cache handlers for different folders? - What are the implications of having multiple caches? - A cache chain or hierarchy? (override) - Multiple CacheSelector's allowed per resource? - One cache handler per resource? - Nested or split Resources with one cache per sub-resource to in effect have multiple cache handlers? - Cache by folder couples the TC context config to the application folder structure. Meh, sounds rather complex, and my brain is tired. :-\ -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC 8.5 cachingAllowed=false ramifications [and potential Resource CacheSelector specification]?
Mark cjb> SPECIFIC: The Excel files are [...] accessed only cjb> once. They don't need to be cached. Is it cjb> possible to declare only the Excel reports output cjb> folder as non-cache-able but leave the (default) cjb> context cache setting as-is so everything else cjb> can be cached in the default way? That is, set cjb> up the Excel report output folder as a separate cjb> "resource" with an independent cache setting? cjb> Right now the Excel folder is embedded in the app cjb> file system: TC/webapps/app/excel. mt> At the moment, no. No reason why we couldn't extend mt> the resources implementation and either add a few mt> more options (based on path and/or filename and/or mt> mime-type and/or whatever). Where we draw the line mt> between 'standard' options and what requires a mt> custom CacheSelector (ideas for better name welcome) mt> is open to debate. Something for an enhancement request? A bare-minimum approach that might work could be a new Resources attribute "cacheNotFoundResults" (default=true). However... [LONG] Something more robust might meet community needs better, depending on what folks require, rather than a one-off fix. Need to specify what the cache implementation applies to. By folder? By file type? What other folks want? I vote for an implementation by folder. How to implement? Move all caching specifications to a new CacheHandler class that the Resource references. The 8.5 Resources docs list these attributes: allowLinking, cacheMaxSize, cacheObjectMaxSize, cacheTtl, cachingAllowed, className, trackLockedFiles (is tLF cache-related?). The decoupled specs of Resources(a) and Cache(b) would start with: a. Resources: allowLinking, className, trackLockedFiles, cacheMaxSize(D), cacheObjectMaxSize(D), cacheTtl(D), CacheSelector(new). - (D): cacheMaxSize, cacheObjectMaxSize, cacheTtl would be deprecated but remain in existing TC implementations (7, 8, 9) to maintain backwards-compatibility. New versions of TC (10+) would not support those options. - CacheSelector would default to the default cache implementation if not specified. Specifying an empty string "" would equate to "none" (no caching), or maybe a no-op canned class of CacheNone could be selected. b. Cache: cacheMaxSize, cacheObjectMaxSize, cacheTtl, cacheNotFoundResults(new), cachedFolder(new). - We could remove the prefix of "cache" to avoid the Smurf syndrome since it applies to cache anyway. - cachingAllowed would be removed since that would be the Cache implementation class itself. - cachedFolder would default to the app deployment folder. The default cache handler CacheHandlerDefault class manages the cache for the app deploy folder(s) by default without changing the TC config. You could specify a canned or custom cache handler at any depth for a different cache implementation for a specific folder set that would override the default. That is, a bunch of folders would have the default cache handler by default, but a special (sub)folder could have a different cache implementation. Questions / Observations: - How to specify different cache handlers for different folders? - What are the implications of having multiple caches? - A cache chain or hierarchy? (override) - Multiple CacheSelector's allowed per resource? - One cache handler per resource? - Nested or split Resources with one cache per sub-resource to in effect have multiple cache handlers? - Cache by folder couples the TC context config to the application folder structure. Meh, sounds rather complex, and my brain is tired. :-\ -- Cris Berneburg CACI Lead Software Engineer
RE: TC 8.5 cachingAllowed=false ramifications?
Mark cjb> RAMBLE: The thing is, it worked in TC 6.0 cjb> but not 8.5. Is it possible a major change cjb> [...] Did TC 6.0 not cache files? mt> The resources implementation was completely mt> re-written for 8.x [...] I'm fairly sure mt> not found results weren't cached in 6.0.x. OK, thanks for explaining the history behind that. cjb> GENERAL: Does the fact that a file does *not* cjb> exist need to be cached? If a cache ping cjb> fails, checking the file system immediately cjb> would make new files available immediately cjb> too, instead of after the cache expires. cjb> (Conversely, how does it handle a file deleted cjb> from the file system still existing in the cache?) mt> Caching not found can improve performance. mt> If a file is deleted, that deletion won't be mt> detected until the associated cache entry mt> expires. Ha, I suspected that. Good to know, thanks. :-) -- Cris Berneburg CACI Lead Software Engineer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC 8.5 cachingAllowed=false ramifications?
Thanks Chris cjb> of TC 8.5.32 on Java 8u181, report output Excel cjb> files won't load (immediately). An error is cjb> displayed to the user. [...] cjb> 1. What are the ramifications of disabling the cache? cjb> IOW, what are the potential side-effects? [...] cjb> 2. Is there a "better" way to specify the setting? [...] cjb> 3. Is there a "better" way to solve the problem? [...] cs> Long ago, we added something similar to what you cs> are talking about. Basically, it was a file- cs> upload capability for images. We waffled about cs> whether to just map the /uploaded-images/ URL cs> space directly to the disk and have DefaultServlet cs> serve the bytes or to write our own servlet [...] cs> Re-reading the documentation for cs> (specifically, ), it seems that: cs> cs>cachingAllowed="false" cs> base="/base/path/to/image/files/" cs> className="org.apache.catalina.webresources.DirResourceSet" cs> webAppMount="/uploaded-images/" /> cs> cs> ... might do the trick, and it would only disable caching for that portion of the disk. cs> cs> Perhaps this would be a better solution, because cs> it only disabled caching for a *portion* of the cs> requests you'll be handling. Yes, exactly! I might experiment with something like that "next". cjb> Is it possible to declare only the Excel reports cjb> output folder as non-cache-able but leave the cjb> (default) context cache setting as-is so everything cjb> else can be cached in the default way? That is, cjb> set up the Excel report output folder as a separate cjb> "resource" with an independent cache setting? cjb> Right now the Excel folder is embedded in the app cjb> file system: TC/webapps/app/excel. Although I wonder if having the Excel folder embedded in the app content folder and specifying it in a "PostResources" clause at the same time would somehow conflict with the default servlet already serving it. -- Cris Berneburg CACI Lead Software Engineer
Re: TC 8.5 cachingAllowed=false ramifications?
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? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TC 8.5 cachingAllowed=false ramifications?
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 cjb> to the 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//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
Re: TC 8.5 cachingAllowed=false ramifications?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Cris, On 10/4/18 09:54, Mark Thomas wrote: > On 04/10/18 14:41, Berneburg, Cris J. - US wrote: >> Hi Folks >> >> Anyone have advice on, experience with, or info about setting >> cachingAllowed=false? >> >> BACKGROUND: >> >> Our customer is suddenly getting a JasperException in production. >> To solve, we're planning to upgrade Tomcat to 8.5.x. In our >> testing of TC 8.5.32 on Java 8u181, report output Excel files >> won't load (immediately). An error is displayed to the user. >> These Stack Overflow topics below point to a cachingAllowed >> setting: >> >> - >> https://stackoverflow.com/questions/44852505/tomcat-8-5-takes-too-lon g-to-recognize-new-content >> >> >> - - https://stackoverflow.com/questions/3743136/how-to-disable-tomcat-cach ing >> >> I added to the in >> TC/conf/context.xml, which solved the problem. >> >> QUESTIONS: >> >> 1. What are the ramifications of disabling the cache? IOW, what >> are the potential side-effects? > > The cache keeps the contents of static files in memory to improve > performance. In theory - the more of your requests that can be > served from memory, the faster the response time. The side effect > is a slower response time. How much actual difference this feature > makes will depend on how much static content there is in your app, > how frequently it is requested and how frequently it is changed. > >> 2. Is there a "better" way to specify the setting? > > Maybe. The change you made applied that setting to ALL web > applications in that Tomcat instance. If you only wanted to apply > it to "/foo" then you would create: > $CATALINA_BASE/conf//foo.xml and add > content something like: /> > >> 3. Is there a "better" way to solve the problem? > > For a given value of "better"... > > What is happening is that: - "something 1" requests the file - the > file is not found and the cache records this - "something 2" > creates the file - "something 3" requests the newly created file - > the cache is still valid so the not found' response is returned - > time passes, 'not found' cache response expires - "something 4" > requests the newly created file which is now returned > > something 1/2/3/4 - may all be different - some may be the same - > may be Tomcat or application code > > What you'd need to figure out is what is "something 1" and what > triggers it before "something 2". With that information, you should > be able to refactor the app so "something 1" doesn't happen or > happens after "something 2". > >> CAVEATS: >> >> a. This is a low-volume application. Little traffic and few >> users. >> >> b. Seeing as we're addressing production, we would like to >> implement a rapid solution. Don't want to refactor the >> application, which would take more time. >> >> THANKS: for your time and assistance! > > Given the caveats, you solution looks to be the best (assuming > performance is acceptable). Long ago, we added something similar to what you are talking about. Basically, it was a file-upload capability for images. We waffled about whether to just map the /uploaded-images/ URL space directly to the disk and have DefaultServlet serve the bytes or to write our own servlet to do the work. We opted to write our own (very basic) servlet to do the work because of our concerns over caching by DefaultServlet / Resources. If you want complete control, you have to take responsibility for that complete control. Re-reading the documentation for (specifically, ), it seems that: ... might do the trick, and it would only disable caching for that portion of the disk. Perhaps this would be a better solution, because it only disabled caching for a *portion* of the requests you'll be handling. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SX0ACgkQHPApP6U8 pFiQlxAAvUP050ASoS/ZbFuEH2bY0On7RozGAZIThJUBlxKVFYOcIeKC6Vz9jB0d IUhBhA4CwXI3Pq908LDkmsV4qtvxwEGb0jhjYc31JThyBWy9Ps9RsPhApFHvt1fR Prdm5/y5PQsi1sU8bYvyA3TIgkgeX5Wh+x/XNh502eR6Y7MaIwrp58u4FzPW9BXx 0/ByD5UCnnpYm7Rhc6+aFB3YzgVrWx04DKgJCp+McjsPpUwVuPsXSG1pqe7Yjp7M EHVRDKmhlB/+UHNPJ+XC8mcFCf0giEFh7k1m9m0jMtCx2hzIe2mt5HYTWi92QtRD Qvko3s/dqtSzqUt2JZoFvG2pyabqsnGNWZmsLQfcHMJXgwRCirRz2rManlHX/qAe 0mbwUc/0wJKyV2P7vcgO9X7tBzqgqIuTbsa11+Qo9xos3/Oi3hDlmo5CdbJ3tX/l QboQnR+5nx2FAkSVfdFblR3eUGBUl8GTX055h0m1KtAw9cOCfaIvyK0Vo681Pahr +4a74tfOH+e+oU7x7pYD+2/7O7d9/1dz4NiCUQNYlMvoLTZJY1A9eDFoxSYajG4Y GfkCJD5kJAiE70lZ7J2rRJLQiA+o+OSjGdHmikYqD00IoK0jJv9nMuNOfDe9FRy7 Q2vAm1yzzkMaZcQPRBFs9RDFw4VtL47j8OpWmFeNdNah2dH4rlg= =QTsR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: TC 8.5 cachingAllowed=false ramifications?
On 04/10/18 14:41, Berneburg, Cris J. - US wrote: > Hi Folks > > Anyone have advice on, experience with, or info about setting > cachingAllowed=false? > > BACKGROUND: > > Our customer is suddenly getting a JasperException in production. To solve, > we're planning to upgrade Tomcat to 8.5.x. In our testing of TC 8.5.32 on > Java 8u181, report output Excel files won't load (immediately). An error is > displayed to the user. These Stack Overflow topics below point to a > cachingAllowed setting: > > - > https://stackoverflow.com/questions/44852505/tomcat-8-5-takes-too-long-to-recognize-new-content > > - https://stackoverflow.com/questions/3743136/how-to-disable-tomcat-caching > > I added to the in > TC/conf/context.xml, which solved the problem. > > QUESTIONS: > > 1. What are the ramifications of disabling the cache? IOW, what are the > potential side-effects? The cache keeps the contents of static files in memory to improve performance. In theory - the more of your requests that can be served from memory, the faster the response time. The side effect is a slower response time. How much actual difference this feature makes will depend on how much static content there is in your app, how frequently it is requested and how frequently it is changed. > 2. Is there a "better" way to specify the setting? Maybe. The change you made applied that setting to ALL web applications in that Tomcat instance. If you only wanted to apply it to "/foo" then you would create: $CATALINA_BASE/conf//foo.xml and add content something like: > 3. Is there a "better" way to solve the problem? For a given value of "better"... What is happening is that: - "something 1" requests the file - the file is not found and the cache records this - "something 2" creates the file - "something 3" requests the newly created file - the cache is still valid so the not found' response is returned - time passes, 'not found' cache response expires - "something 4" requests the newly created file which is now returned something 1/2/3/4 - may all be different - some may be the same - may be Tomcat or application code What you'd need to figure out is what is "something 1" and what triggers it before "something 2". With that information, you should be able to refactor the app so "something 1" doesn't happen or happens after "something 2". > CAVEATS: > > a. This is a low-volume application. Little traffic and few users. > > b. Seeing as we're addressing production, we would like to implement a rapid > solution. Don't want to refactor the application, which would take more time. > > THANKS: for your time and assistance! Given the caveats, you solution looks to be the best (assuming performance is acceptable). Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
