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
Its also possible to set the Expiry per element.
http://ehcache.sourceforge.net/
EhcacheUserGuide.html#supportcachewideorelementbasedexpirypolicies
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 ?
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.
