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
