tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berneburg, Cris J. - US" <>
Subject RE: TC 8.5 cachingAllowed=false ramifications [and potential Resource CacheSelector specification]?
Date Tue, 09 Oct 2018 18:03:41 GMT

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"

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

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

View raw message