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? > > So you can use ehcache now and configure one of its cluster wide > invalidation transports (not much sense in replicating ?), of JCS once its > fixed or something else. > > But Kevin should comment on the requirements as I don't think caching is > finished ? > > > > HTH > Ian > > > If you want the patch updating, let me know I have a local git branch of it > so its relatively easy. > > > > > On 4 Jun 2008, at 16:37, Marijn Speelman wrote: > > Hi, >> >> I've got a couple of questions related to gadget caching in Shindig >> (Java). >> >> - Caching of rendered gadgets >> I've been looking through the code and as far as I can see only the >> Gadget specs (external XML files) are cached, in memory. Is this >> observation correct? If so, wouldn't it make sense, performance wise, to >> cache the rendered gadgets as well? I have no data on the performance of >> the Gadget rendering (XML -> HTML+JS), but it would probably be best to >> cache as close to the presentation of the gadget as possible. >> >> - Distributed cache >> We're going to run Shindig on multiple (10+) servers to share the load. >> At the moment Shindig only caches per instance on each server, so for >> these kind of distributed setups it would be nice to have a distributed >> caching system buldin. I'm planning to implement a Memcached backend for >> this (because we already have a large memcached pool), but I was >> wondering if anyone else is already doing the same or working on >> something similar. I'm also curious about the progress on these two >> tickets: >> * https://issues.apache.org/jira/browse/SHINDIG-173 >> * https://issues.apache.org/jira/browse/SHINDIG-279 (although this is >> related to an ehcache implementation, it could be useful). >> >> Thanks in advance, >> >> Marijn Speelman >> >> >
