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. >> >> >
