[MGNLADVCACHE-17] ServeUntilRecachedPolicy and NotifyFlushListeningPolicy don't work with policies sets Created: 19/Apr/11 Updated: 06/Jun/11 Resolved: 06/Jun/11 |
|
| Status: | Closed |
| Project: | Advanced Cache |
| Component/s: | None |
| Affects Version/s: | 1.3 |
| Fix Version/s: | 1.3.2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Christian Kutschke | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| 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 |
|
We have got a problem with the advanced cache in our Magnolia 4.4.2 EE setup. In our developing/testing environment this works fine. The problems occur on our productive environment:
The problem seems to be, that the cache is never invalidated:
Two observations:
One more thing: as I understand it, the keys for the cache are the URLs of the pages. Could it be, that our setup with 2 public nodes with distinct URLs (which work fine cache wise) are accessed through another URL (via netscaler) generates problems with this caching policy? Such as, the URL accessed (www.domain.de/test.html) is never invalidated, the 2 nodes only invalidate their own respective caches with keys/URLs like public01.domain.de/test.html and public02.domain.de/test.html). Page headers are set to "don't cache at all" (i.e. "Expires = 01.01.1970", "Cache-Control = no-cache, no-store, must-revalidate, max-age=0", "Pragma = no-cache") and still the old content is shown in the browser. So it can't be the netscaler caching content based on headers. Also browser cache can't be an issue, because it is disabled. Is this a common issue? How do we work around it? We would really like to use the ServeUntilRecachedCachePolicy as it fits our requirements the best. Read the enclosed logfile as follows:
|
| Comments |
| Comment by Christian Kutschke [ 27/Apr/11 ] |
|
Do you need mor information? Has anyone looked in this issue yet? |
| Comment by Jan Haderka [ 11/May/11 ] |
|
could you please provide me with your exact cache and filter chain configuration? Go to Configuration and export config:/server/filters and config:/modules/caches/config from the public instance and attach it to this issue or to the related support ticket. Since you get the correct response when accessing Magnolia nodes directly I'm bit at loss what the cause could be. |
| Comment by Jan Haderka [ 11/May/11 ] |
|
Renaming of the CachedPage to CachedEntry invalidates checks in advance cache strategies, thus making such strategies unusable since Magnolia 4.4. |
| Comment by Christian Kutschke [ 11/May/11 ] |
|
Some additional information on the netscaler:
Manual test on the tomcat server (one of the productive nodes):
Varying the host header (e.g. to the specific node host names) yielded different results. If the host header matches the subscriber configuration latest content is returned, using the cluster name old content from cache is served. |
| Comment by Jan Haderka [ 12/May/11 ] |
yeah, that makes sense. The cache key is composed of the server name among other things so using the original name retrieves old unflushed cached content. While the local name of the node results in different key thus generating new entry and masking the original problem. Thanks for all the info. |
| Comment by Christian Kutschke [ 27/May/11 ] |
|
We updated our setup to Magnolia EE 4.4.4 and Advanced Cache 1.3.1 as suggested. Our setup ist still the same:
So basically the same result - from my point of view nothing has changed. Could you please look into it again or give me details on what you changed in the advanced cache module? Best regards, |
| Comment by Jan Haderka [ 28/May/11 ] |
|
could you please clean up the cache manually, then enable debug level logging for cache and attach the log file from the try to this issue? The detailed changes are visible in the "Subversion Commits" tab on this issue. The problem we identified originally was that when policies are chained and wrapped in the delegate classes, module was not able to unwrap them anymore. This is now replaced by obtaining policies configuration data such as last update timestamp directly via module class. Regards, |
| Comment by Christian Kutschke [ 30/May/11 ] |
|
Hi Jan, see enclosed the requested files. The test setup is the following:
Testing always consists of the following steps: 1. Activate new content to clean cache
2. Change and activate
3. Clear cache again
Bets regards, |
| Comment by Christian Kutschke [ 30/May/11 ] |
|
Magnolia DEBUG cache log for info.magnolia.module.cache and info.magnolia.module.advancedcache |
| Comment by Christian Kutschke [ 30/May/11 ] |
|
Module config for advanced cache |
| Comment by Christian Kutschke [ 30/May/11 ] |
|
Another thing I noticed: Also the timestamps look like they are never updated (always 0). |
| Comment by Jan Haderka [ 31/May/11 ] |
|
Hi Christian, Could you please download this jar and replace your current magnolia-advanced-cache-1.3.1.jar with it? Once you confirm the functionality we will release this as version 1.3.2. Thanks you. |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Hi Jan, thanks for the update, unfortunately I see no changes in the behavior. Also the values of lastUpdateTimestamp in the module config still never get changed (remains '0' forever). I enclosed the two files (from author and public) for you. BTW: the caching issue never occurs on two author instances (probably because authors don't cache at all?). But if I change the publisher instance to admin=false, it's the same issue as before. Best regards, |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Author's module config of advanced cache. |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Publishers config of module advanced cache. |
| Comment by Jan Haderka [ 31/May/11 ] |
|
Content is not cached on the author (and even on public) when you are actually logged in. To understand this better you might want to have a look at config:/modules/cache/config/configurations/default/cachePolicy ... there is whole voter chain setup that allows you to control what will get cached and what not on the very low level. Back to the issue at hand, could you please export the cache configuration from config:/modules/cache/config/configurations/default so I can double check it is setup properly? Is the error in the logs still the same as before? Could you attach the log (from public instance) from attempt to activate something with the advanced-cache snapshot at public instance? Thanks. |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Cache-Config |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Updated Cache Log (new entries starting with 31.05.2011 16:07:13). Contains 2 activations, both not reflected on 1 node, then clearing of cache and correct result on both nodes. |
| Comment by Christian Kutschke [ 31/May/11 ] |
|
Hi Jan, see enclosed the requested files. Best regards, |
| Comment by Jan Haderka [ 03/Jun/11 ] |
|
Hi Christian, |
| Comment by Christian Kutschke [ 06/Jun/11 ] |
|
Hi Jan, thank you for the pointer - I reinstalled the cache and advanced Cache modules from scratch, reconfigured them following the howto and it seems to work now on my test system - at least it looks promising! I'll have the final result after I can redeploy to our productive environment (as only here we have the real setup with cluster and netscaler). I'll report the results asap. Thanks for your time and patience - pity if the answer is this bootstrap hiccup. Best regards, |
| Comment by Christian Kutschke [ 06/Jun/11 ] |
|
Could you provide the temporary fix of the advanced cache module as a permanent 1.3.2 in the repository? Thank you! |
| Comment by Jan Haderka [ 06/Jun/11 ] |
|
Sure. The fix will be released as 1.3.2. |