I have a page that is a mashup of two internal web services - one that serves organization structure, and another that serves IM presence indicators - to produce a team listing for each of the groups that own the content of one of our XWiki instances. Because queries to the first are costly and their content is updated infrequently, a caching mechanism is indicated. I see two ways of doing this: one is to manipulate the URL object for the outgoing request to provide for normal HTTP caching disciplines. I'd prefer to do it this way, but haven't a clue at the moment of how to do it, since it's inside org.dom4j.io.SAXReader, to whose read(String) method I pass a URL. Another way that I'd like to investigate in parallel is simply to use XWiki's caching mechanism to cache the parsed org.dom4j.Document objects that are returned. Establishing a new cache with a Velocity script seems straightforward (though of course it requires programming rights): #set($myCache = $xwiki.xWiki.cacheService.newCache()) $mycache.put("name", $myObject) $myCache.get("name") ... etc... but it suffers from two problems: first, it's only in the context of the request, making it useless; second, there's no way to manage the freshness exception thrown from the get methods. So apparently a plugin is indicated; ideally, one that: could be used for any purpose; provided simple means of specifying cache parameters, such as the freshness rules and the operation required to refresh the cache. I think that the best way to use it would look something like: #set($myCache = $xwiki.myCachePlugin) $myCache.setParameters(...) $myCache.cached('$velocityCode') ## should pass the Context, or is that part of the plugin API? The method would use the unrendered Velocity code as the key to the cache, look first in the cache and return it, rendering the code and caching its result first if the value was not fresh. In describing this, I'm thinking that the DefaultPlugin actually provides for a lot of this. Thoughts, anyone? brain[sic]
Hi Brian, What you are trying to do sounds quite cool ! You can either store your cache object in your plugin (but not in the API wrapper which is request specific). An easier way is to store it in the Servlet context. You can get the servlet context using $context.context.getEngineContext() You then have access to getAttribute and serAttribute This is a priviledge script Ludovic THOMAS, BRIAN M (ATTSI) a écrit :
I have a page that is a mashup of two internal web services - one that serves organization structure, and another that serves IM presence indicators - to produce a team listing for each of the groups that own the content of one of our XWiki instances. Because queries to the first are costly and their content is updated infrequently, a caching mechanism is indicated.
I see two ways of doing this: one is to manipulate the URL object for the outgoing request to provide for normal HTTP caching disciplines. I'd prefer to do it this way, but haven't a clue at the moment of how to do it, since it's inside org.dom4j.io.SAXReader, to whose read(String) method I pass a URL.
Another way that I'd like to investigate in parallel is simply to use XWiki's caching mechanism to cache the parsed org.dom4j.Document objects that are returned. Establishing a new cache with a Velocity script seems straightforward (though of course it requires programming rights):
#set($myCache = $xwiki.xWiki.cacheService.newCache()) $mycache.put("name", $myObject) $myCache.get("name") ... etc...
but it suffers from two problems: first, it's only in the context of the request, making it useless; second, there's no way to manage the freshness exception thrown from the get methods. So apparently a plugin is indicated; ideally, one that: could be used for any purpose; provided simple means of specifying cache parameters, such as the freshness rules and the operation required to refresh the cache.
I think that the best way to use it would look something like:
#set($myCache = $xwiki.myCachePlugin) $myCache.setParameters(...)
$myCache.cached('$velocityCode') ## should pass the Context, or is that part of the plugin API?
The method would use the unrendered Velocity code as the key to the cache, look first in the cache and return it, rendering the code and caching its result first if the value was not fresh.
In describing this, I'm thinking that the DefaultPlugin actually provides for a lot of this.
Thoughts, anyone?
brain[sic]
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic
What you are trying to do sounds quite cool !
Huh. Well, thanks; coming from an ex-Netscaper ("Netscapee"?) who has, at one time at least, been on the leading edge of cool, I take that as high cred. By the way, to which did you refer: my self-styled "mashup" or the generic read-thru cache plugin idea? I finally wended my way through the maze of run-time indirections to where I could get a reference to the XWiki cache that was not scoped only to the request, and it works fine, even from Velocity, as long as I avoid any chance of that NeedsRefreshException, which I did initially by always getting the object from the cache, with a never-expiring freshness parameter, and optionally calling the method to load it immediately beforehand.
You can either store your cache object in your plugin (but not in the API wrapper which is request specific). An easier way is to store it in the Servlet context.
Yes, I know I can do it in a plugin, which can easily have its own cache with its own rules and its own namespace (in fact, I note that the plugin interface has APIs to whack its cache, and also that many of XWiki's cache keys are pretty short and not terribly unique, so I was careful to put a fairly long hierarchical-style prefix on all my key values); but I just wanted to see if I could do it from within Velocity so that I could do a quick proof-of-concept. And of course I could dispense with plugins and cache parameters entirely if the URL handling within org.dom4j.io.SAXReader.read(String) could be configured to cache responses just like a browser does. Working inside the plugin will allow me to catch the XWikiCacheNeedsRefreshException and refresh the cache, then get it again and return the value. Or, there may be an even easier way to do it, seeing that the OSCache object has some concept of listener objects. Another thing I'd like to do is automatically and pre-emptively preload a cache entry before it expires, to avoid hanging any real-time requests. Also, the presence indicator images, though they have only three or four distinct values, are cached by the URL of the request - for the individual user - so they have to be requested for every user. What I plan to do is have XWiki cache the status and send only the three or four URLs for the image tags to the browser, which will load them at most once per page. To do either this or the above requires that I have some kind of mechanism in XWiki that is more or less autonomous, rather than only in response to a request. But as far as I know, nothing happens in XWiki - including loading the context - until it gets a request, and I don't even know whether a servlet can do anything autonomously, so that will take more investigation. Thanks again... brain[sic]
participants (2)
-
Ludovic Dubost -
THOMAS, BRIAN M (ATTSI)