Re: TC 8.5 cachingAllowed=false ramifications?

2018-10-10 Thread Christopher Schultz
-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]?

2018-10-09 Thread Igal Sapir

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

2018-10-09 Thread Berneburg, Cris J. - US
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?

2018-10-09 Thread Berneburg, Cris J. - US
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?

2018-10-09 Thread Berneburg, Cris J. - US
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?

2018-10-04 Thread Mark Thomas
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?

2018-10-04 Thread Berneburg, Cris J. - US
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?

2018-10-04 Thread Christopher Schultz
-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?

2018-10-04 Thread Mark Thomas
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



TC 8.5 cachingAllowed=false ramifications?

2018-10-04 Thread Berneburg, Cris J. - US
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?

2. Is there a "better" way to specify the setting?

3. Is there a "better" way to solve the problem?

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!

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