On Jul 30, 2010, at 10:11 AM, Bert Leunis wrote: > Hello all, > > After more tests I can refine my question about the uuid-key-mapping cache. I > built and used the > FlushSubpathCacheListeningPolicy as shown in Jans blog > (http://weblogs.java.net/blog/rah003/archive/2010/03/24/flush-cache). It > works very well. I have these caches now: > > uuid-key-mapping > default > siteA > siteB > > When I activate a page for siteA, three caches are flushed: siteA, default, > uuid-key-mapping. The cache for siteB is untouched, what is exactly what I > want. > > I think that the flushing of the uuid-key-mapping cache is unwanted though. > There may be uuid's stored that reference elements of the cache of siteB. If > you now lookup a uuid belonging to siteB in the uuid-key-mapping cache, > because you want to flush all elements belonging to that uuid, you will not > find it. And the element for that uuid remains in the cache of siteB. > > I hope I describe this situation correctly. Do you agree with me on this > problem? I think not flushing the uuid-key-mapping cache is the solution > here. There may stay extra keys in there, that reference elements that are > already flushed, but that seems not such a big problem to me.
Yes you are right, the uuid-key-mapping should not be touched. It's better to have obsolete keys then the missing ones. To fix that you can just remove all the repositories from the .../uuid-key-mapping/flushPolicy/policies/flushAll/repositories > > > Yeah, bypass should work as long as all the images are in that same place. > Wrestling with the voters, but they all voted against me, I had no luck there. probably case of reversing some of the voters or increasing the "level" so it can override the others (like the site voter) > But adapting the site-configuration did the job! Images with a url starting > with "/.imaging/stk/hollanddoc" are now recognized as being part of the > hollanddoc site by the SiteURIPatternVoter. > > In /modules/extended-templating-kit/config/sites/hollanddoc/mappings: > - imaging > +-- URIPrefix = /.imaging/stk/hollanddoc > +-- handlePrefix = /.imaging/stk/hollanddoc > +-- repository = imaging Cool. Glad you found a working solution. > Now I am trying to grasp the purpose of the uuid-key-mapping cache. I think I > understand what you wrote in your blog about that > (http://weblogs.java.net/blog/rah003/archive/2010/03/10/cached-again). When > an item with a uuid X is changed, using the uuid-key-mapping cache you can > find all items in the default and other caches that contain cached content > regarding uuid X. All these elements should be flushed. Is an implementation > of this mechanism already used? Yes, this mechanism is used for flushing pages with enabled commenting. When the comment is made on the page, this is public-only change and this mechanism is used to find and flush only the pages associated with the comments. > I hope you have some time to answer this question too. As always... much > obliged! sorry for letting you wait, I was off for last couple of days ... Jan > Thanks, Bert > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
