[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: When I requested: a file was created in the cache: 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 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? 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: 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 The basic problem is that directories and files share the same name space. Which leads me to option 4 and 5: 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?
|
| 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 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 |