On Jun 4, 2008, at 9:36 AM, Kevin Brown wrote:
On Wed, Jun 4, 2008 at 8:54 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
I did the ehcache impl in SHINDIG-279 about 2 weeks back, but there
are
some other requirements that have come in that this doesn't take into
account, like variable cache timeout on an payload by payload basis
(from
the headers of the httpresponse on the remote server). However,
that should
be easy enough to add (happy to do it if there is demand).
There is also a Apache JCS cache implementation, which requires
that the
key and payload are serializable. For some reason which I haven't
worked out
yet they serialization tests pass on the objects, but the cache
unit tests
fail with JCS.... so that patch isn't working (yet, lack of time
not tech
barrier IMHO). For Obvious reasons, Apache JCS would be the better
solution.
One other cache worth thinking about is memcache. I believe there
is a JNI
binding to this, and although it takes non Java setup to make it
work, its
widely used. Apparently Memcached will be part of the Google App
engine....
which I though I heard form someone would run java apps in the
future? (or
was that just a sensible suggestion)
I can't comment on the app engine parts, but there are several
implementations of memcached clients for Java. Some are native java,
some
are JNI.
Paul has some experience with this -- care to share?
Memcache is good for what ails you. We're using the meetup.com / Greg
Whalin client from http://danga.com/memcached/ (with a bunch of site-
local hacks). Dustin Sallings library is also very very good (http://code.google.com/p/spymemcached/
)
In our current implementation we actually injected caching in the
contentfetcher. We maintain a whitelist of known/approved gadget spec
URLs and use the cached content wherever possible.
This allows some nice features in our developer console, such as the
'Refresh' button that injects content into the cache directly.
We also have a CDN in front of our shindig servers. This caches the
rendered IFrames. I'm of the opinion that it's better to have a
common consistent app-bundle with only variations per-language/per-
country. We put the skin parameters and parentURL params in the hash
portion of the url for that very reason.
