[MAGNOLIA-1088] Creating cache file blocks later creation of cache directories which blocks further caching. Created: 27/Sep/06  Updated: 23/Jan/13  Resolved: 27/Jun/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 3.1 M2

Type: Bug Priority: Major
Reporter: Chris Miner Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

I created a web site with the following page structure:
test_root
test_root/level10
test_root/level10/level20

When I requested:
http://localhost:8180/magnolia/test_root/level10

a file was created in the cache:
rw-rr- 1 chris users 4529 2006-09-27 18:50 level10

unfortunately this means subsequent requests to sub pages are blocked from caching, because creating the required 'level10' directory fails.



 Comments   
Comment by Sameer Charles [ 03/Oct/06 ]

Its more of a templating bug then caching, there is no extension to the URL you are requesting
that's why you see such a behaviour, in this case not only caching but some other filters like ContentType which
sets the Mime type based on the extension would fail.

In my opinion Its a good practice to avoid such calls

Comment by Chris Miner [ 04/Oct/06 ]

It isn't a templating bug so much as a templating feature. The code base seems to suggest that handles are used to find content. Content is checked for being a page. The the data in the page is consulted to determine a template name. Only then is the extension consulted to check for an optional sub template.

It seems to me that the majority of evidence suggests that requesting pages without extensions is meant to be supported. While this may or may not be good practice, it is nonetheless a feature of the current product. So it would seem that the default caching system should account for this.

Besides in CacheFilter.doFilter, the code gets a key from the cache manager, then uses this provided key to tell the cache manager to cache the response. Certainly it is a bug that the cache manager hands out keys it can't actually use in caching? (i.e. keys that when used mean that the subsequent call to cacheRequest(CacheKey, CacheableEntry, boolean) fails.)

Comment by Sameer Charles [ 04/Oct/06 ]

> Certainly it is a bug that the cache manager hands out keys it can't actually use in caching?
you have to realize that file system cache is not the only implementation available with magnolia, for cache manager its a valid request for cache.
its the file system impl which fails, on the other hand this cache also used for other workspaces not only website where it might make sence to cache a item which is not a page and cannot have sub items.

I can fix it with a simple check but in that case your application will suffer because these requests will never be cahed.

Comment by Chris Miner [ 04/Oct/06 ]

I had thought of two ways to solve the problem:
1. The cache key could include the default html extension.
2. The directories used in the cache could be named such that collisions don't occur.

I don't like the first solution because it is the result of knowlege of how other parts of the system work. When the day comes that handles without extensions aren't accepted anymore it doesn't make sense. And could lead to confusion.

I am partial to the second solution, since creating directories is an artifact of the implementation. The directory structure isn't absolutely required. It isn't the fault of the client (in this case info.magnolia.cms.cache.CacheFilter) of the caching system that the caching system creates a directory structure that keeps it from doing its job later.

Comment by David Smith [ 04/Oct/06 ]

I vote for number 2. A special extension like .___ (3 underscores) could easily indicate no extension. Fixing the file system cache implementation is IMHO ideal.

Comment by Chris Miner [ 04/Oct/06 ]

Okay, that makes me think of option 3
3. The files used in the cache could be named such that collisions don't occur.

The basic problem is that directories and files share the same name space. Which leads me to option 4 and 5:
4. Only use one directory and give each file in the directory a name based on the CacheKey. No directories no collisions.
5. Put each cache entry in its own directory using the CacheKey as a directory name, and store the entry as a file named "entry". No sharing of directories, no collisions. Every entry would sit in it's own directory.

Option 5 isn't much different than what already exists.

Comment by Sameer Charles [ 04/Oct/06 ]

I would go for option 5, option 4 might create problems on some filesystems if number of nodes reaches a limit.

If I understood you right, you will have multiple entries under a given cacheKey represented by a directory?
something like:

  • entry.html
  • entry.html.gzip
  • entry.pdf
  • and so on
Comment by Chris Miner [ 05/Oct/06 ]

With option five I was thinking of creating a directory based on the cacheKey, then sticking the thing being cached in that directory. That way every cacheable uri has its own directory, and in that directory is the cached response. Something like:

.../cache/test_root/help.pdf/entry
.../cache/test_root/help.pdf/entry.gzip
.../cache/test_root/level10/entry
.../cache/test_root/level10.html/entry.gzip
.../cache/test_root/level10/level20/entry.gzip
.../cache/test_root/level10/level20.html/entry
.../cache/test_root/level10/level20.html/entry.gzip

Where the cach key is used to create a directory on the file system, and then the cached value is placed in that cache key location. I could also imagine the 'entry' files having the requested suffix, since that might be useful/helpful from an implementation standpoint.

Comment by David Smith [ 05/Oct/06 ]

Just a comment from the peanut gallery – option 5 has my vote. Supports the equivalent of traditional web server default pages (ie no .html on the end) as well as url selectors.

Comment by Teemu Matilainen [ 22/Jan/07 ]

The option 5 will still be suffering from the possible collision of chosen name (e.g. "entry"). For example urls "/test_root/level10" and "/test_root/level10/entry" would collide. Options 2 and 3 share the same problem. So the name/suffix should be chosen to be very unlikely in the context. And documented.

Btw, is there any schedule for fixing this issue?

Comment by Philipp Bracher [ 27/Jun/07 ]

Solved by adding .cache extension to the directories

Generated at Mon Feb 12 03:23:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.