In addition to what Ian has said, there are actually two caches: - HTTP level. Generally best implemented as a distributed cache, since there will be lots of files here. - Manifest (Gadget / message bundle xml) level. Best implemented as an in-memory cache.
The default implementations of both caches are in memory, but if you're scaling up I'd recommend using a distributed cache for HTTP (and strongly recommend keeping the in-memory cache for the xml files). As far as caching policy goes, the specification *requires* that we do two things: 1. Honor HTTP cache-control headers by default. 2. If the user specified a parameter in the request (say, in getProxyUrl or makeRequest, or by rewriting), honor the cache time that they've specified. For gadget specs, the rules are not well defined, but the de facto standard is to cache the files for a reasonably long time period (usually 1 hour). On Fri, Aug 29, 2008 at 3:45 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > For Java Shindig: > > The default cache is entirely in memory, wont page to disk and doesn't have > distributed capabilities, but is light fast and works perfectly well. > > However > In the current code base there is an implementation of the CacheProvider > for EhCache which will do distributed Cache for you. > > Its not active by default, you need to add the EhCacheGuiceCacheModule to > the list of modules that are loaded. > The configuration is in 2 places, ehcache.properties for the shindig > specific settings, like JMX stats and the location of the ehcache xml > configuration file, currently on the classpath at > /org/apache/shindig/cache/ehcache/ehcacheConfig.xml > > You should consult ehcache documentation to configure distribution and > paging to disk http://ehcache.sourceforge.net/EhcacheUserGuide.html > > I have an Apache JCS implementation in waiting to go in, and there may be a > memcachd impl in the pipeline. > > > Code: > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > src/main/java/org/apache/shindig/common/cache/ehcache/ > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > src/main/bundle/ehcache.properties > http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/common/ > src/main/bundle/org/apache/shindig/common/cache/ehcache/ehcacheConfig.xml > > The location may change as we get closer to a 1.0 release. > > HTH > Ian > > > > > > On 29 Aug 2008, at 10:14, Eran Galili wrote: > > Hi, >> >> I started implementing a container using shindig as my gadget server and I >> have a few questions regarding the way shindig gets and caches the gadget >> XML. >> >> First, I'd like to know what's considered the best practice for the >> expiration time of cached gadgets? Does it have to be in some kind of >> range >> for my container to be spec compliant? >> >> Secondly, does shindig cache the gadgets only on the machine's memory, or >> does it also support using a distributed cache? If i set a very long time >> for my container to update the gadget XML (and perhaps allow the developer >> "update me" functionality), would it be reasonable to save it on my >> database >> (maybe save it already parsed)? >> >> Also if i keep an "Application Directory" of approved apps that i allow on >> my container, is it really necessary to send the gadget XML URL to when >> sending a gadget rendering request? If i implement my own gadget server, >> could i simply send an application Id (managed by my site) and on the >> server >> side get the appropriate URL for that application (or even the XML itself >> from the cache)? >> >> I'm asking these questions because i think I'm missing something. I would >> like to minimize the amount of times my servers have to parse the gadget >> xml. Saving the gadget spec already parsed would allow me to do that. >> >> Thanks in advance, >> Eran >> > >
