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
