On Sun, May 18, 2008 at 3:13 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
> I have a feeling that ehcache allows to write your own replication agents. > For invalidation only, its just the key that needs to be serializable. That > might be enough. > http://ehcache.sourceforge.net/EhcacheUserGuide.html#id.s4.5.2 > http://ehcache.sourceforge.net/EhcacheUserGuide.html#id.s20.1 Reading that indicated to me that Serializeable is the norm, and the custom agents are for serializing objects that you can't modify to support it. <http://ehcache.sourceforge.net/EhcacheUserGuide.html#id.s20.1>Its also > possible to set the Expiry per element. > http://ehcache.sourceforge.net/ > EhcacheUserGuide.html#supportcachewideorelementbasedexpirypolicies This is definitely useful. But that still requires that the body of the element is, and its also going > to be required for most other cache implementations. serializable. > > Did you still want a memcachd impl ? If someone wants to contribute one, I'm sure people who are using memcache will appreciate it, but having at least one production-worthy caching implementaiton was my original goal with SHINDIG-173 > > Ian > > > > > On 18 May 2008, at 22:52, Kevin Brown wrote: > > On Sun, May 18, 2008 at 2:12 PM, Ian Boston <[EMAIL PROTECTED]> wrote: >> >> I have implemented a JCS cache and initially it looks a lot cleaner, but >>> then I started to get lots of errors with the message >>> >>> Caused by: org.apache.jcs.access.exception.CacheException: >>> org.apache.shindig.gadgets.http.HttpResponse >>> at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:285) >>> at org.apache.jcs.access.CacheAccess.put(CacheAccess.java:249) >>> at >>> >>> org.apache.shindig.common.cache.ConfiguredCache.addElement(ConfiguredCache.java:54) >>> >>> with full debug on there is no further information, (btw, it has to have >>> log4j configured and present, but perhapse that can be changed). >>> >>> searching google reveals >>> http://markmail.org/message/ >>> >>> cd55im2xm455kxyg#query:org.apache.jcs.access.CacheAccess.put(CacheAccess.java)+page:1+mid:ofd5ljhpm4tfap47+state:results >>> >>> "Your keys and values must be serializable. Although >>> the JCS api suggests that you can cache any object, >>> you must only cache serializable objects. This is a >>> known issue with no good solution. " >>> (date 12 June 2006, version 1.3 from the list) >>> >>> https://springmodules.dev.java.net/docs/reference/0.8/html/cache.html >>> appears to confirm this.......... >>> >>> so IMHO, if that is the case JCS is a non starter for this in memory use >>> case, all descendant objects of whatever is put in the cache will have to >>> be >>> serializable. >>> >> >> >> I'm not terribly fond of requiring this, either, but it seems to me that >> this would be a necessity for the distributed cache anyway. This was a big >> part of the reason that I left the base interface as simply Key->Value >> caching. This allows custom caches for specialization (as we have with >> HttpCache) that can implement custom serialization / deserialization as >> needed. The only viable way to implement generic distributed caching would >> be to require that the objects extracted from or inserted into the cache >> be >> able to support serialize and deserialize routines. >> >> Another motivation for the generic cache interface is that we are going to >> need a few different types of caches in the near future -- simply doing >> HTTP >> caching is insufficient. Cases where we'll want caching: >> >> - Cached GadgetSpec objects (to avoid performance problems with rewritten >> content) >> - Cached blobs (because rewriting / caja is expensive) >> >> I'm sure there will be others as well. >> >> >> >>> Ian >>> >>> >>> >>> On 18 May 2008, at 20:38, Henning Schmiedehausen (JIRA) wrote: >>> >>> >>> [ https://issues.apache.org/jira/browse/SHINDIG-279 >>>> ?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597834#action_12597834 >>>> ] >>>> >>>> Henning Schmiedehausen commented on SHINDIG-279: >>>> ------------------------------------------------ >>>> >>>> Uhm, as a "default, this is how a cache should look like" >>>> implementation, >>>> this is likely to be overkill. And it drags in another dependency which >>>> in >>>> turn might drag in others. I'd say that the shindig core itself should >>>> be as >>>> lean as possible. An ehcache based, production-ready cache is nice but >>>> is it >>>> needed to get started? Does it add complexity that is not needed to get >>>> the >>>> sample container running? >>>> >>>> An Apache project need not to have an preference towards fellow Apache >>>> projects. EHCache is fine, as long as the license is compatible (which I >>>> believe it is). We should never sacrifice technical advantages just for >>>> the >>>> sake of "using another Apache project" but judge all projects based on >>>> technical merit and then decide. >>>> >>>> Configurable and clusterable cache for Gadgets server >>>> >>>>> ----------------------------------------------------- >>>>> >>>>> Key: SHINDIG-279 >>>>> URL: https://issues.apache.org/jira/browse/SHINDIG-279 >>>>> Project: Shindig >>>>> Issue Type: Improvement >>>>> Components: Gadget Rendering Server (Java) >>>>> Reporter: Ian Boston >>>>> Attachments: SHINDIG-279.patch >>>>> >>>>> >>>>> If the the Gadgets server is going to perform caching, then a >>>>> configurable cache that has all the features that you might expect in >>>>> production. Attached is a patch to put ehcache behind the Cache >>>>> interface >>>>> and introduce a ShindigCacheManager, that registers with JMX for >>>>> statistics >>>>> and management. >>>>> The patch is fully integrated into the gadgets server guice config, >>>>> with >>>>> tests for each class. It also appears to startup Ok. >>>>> >>>>> >>>> -- >>>> This message is automatically generated by JIRA. >>>> - >>>> You can reply to this email to add a comment to the issue online. >>>> >>>> >>>> >>> >
