You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Ian Boston (JIRA)" <ji...@apache.org> on 2008/05/18 16:48:55 UTC
[jira] Created: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
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
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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597823#action_12597823 ]
Kevin Brown commented on SHINDIG-279:
-------------------------------------
This looks like a useful addition (see SHINDIG-173), though there are a couple of issues:
- Several style issues (mostly whitespace and wrapping)
- Anything configured for common belongs in the common artifact. A new properties file in common/conf would probably be appropriate.
- Since it appears that ehcache provides a good LRU implementation, it would make sense to just stick with that as the default and get rid of the one I threw in there.
- BasicHttpCache can probably become DefaultHttpCache; I believe this configuration would make this production-worthy for a large number of deployments. Some of us will still use our own caching solution, but not many.
- The default config should have a higher TTL. Cached files should be explicitly expired by their http headers, not based on an arbitrary timestamp.
- The Cache itself needs to be injected to facilitate easier testing. Most tests should use a no op cache.
> 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597824#action_12597824 ]
Kevin Brown commented on SHINDIG-279:
-------------------------------------
Also, has anyone done a comparison between ehcache and JCS? http://jakarta.apache.org/jcs/JCSvsEHCache.html claims that JCS is better, but the ehcache site claims the same. I have a bit of a bias towards using Apache projects (as we should), but at the same time I want to make sure we're offering a solid solution for our users beyond politics.
> 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603506#action_12603506 ]
Kevin Brown commented on SHINDIG-279:
-------------------------------------
Sorry for the late follow up on this one. You've done great work Ian -- thank you.
Does anyone have a strong opinion one way or another here? Perhaps we could make separate artifacts for each of these and extract out the caching-related parts of the Guice module to simplify integration and let people choose which option to go with?
> 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-jcs.patch, 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279.patch
Cleaned up formatting, modified expiry.
the ShindigCacheManager is configured so that there can be multiple instances in the JVM with different configurations, consequently the config file is owned by the application that uses the cache. It could be configured so that there was only one config file, but then social and gadget specifics would get into common (only in the config however)
> 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279.patch
Patch produced by git, hope the headers are Ok. Let me know if not.
> 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279-provider.patch
Updated the patch to change the name of the cache provider property.
> 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-jcs.patch, SHINDIG-279-provider.patch, 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604278#action_12604278 ]
Ian Boston commented on SHINDIG-279:
------------------------------------
There are 2 cache provider implementations at
https://source.sakaiproject.org/contrib/tfd/trunk/shindig-cacheproviders
One for EhCache and one for Apache JCS. They are work in progress, as I am adding tests to validate the implementations.
> 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-jcs.patch, SHINDIG-279-provider.patch, 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: (was: SHINDIG-279.patch)
> 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: (was: SHINDIG-279.patch)
> 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-provider.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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279-provider.patch
This patch creates a CacheProvider interface for which there is a DefaultCacheProvider that creates instances of the LruCache.
The codebase only binds to the CacheProvider which is injected through in the default Guice module, and could be replaced by any other implementation delivering other cache implementations to Shindig.
Separately I will implement some CacheProvider implementations.
> 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-jcs.patch, SHINDIG-279-provider.patch, 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: (was: SHINDIG-279-jcs.patch)
> 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-provider.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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: (was: SHINDIG-279-provider.patch)
> 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-jcs.patch, SHINDIG-279-provider.patch, 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603534#action_12603534 ]
Ian Boston commented on SHINDIG-279:
------------------------------------
I should add for clarity,
1. I think that the patches need to be reworked to make them Ok for
trunk, issues with element expiry (happy to do)
2. the JCS patch failed to pass unit tests I think due to a worrying
serialization faliure (tested seperatedly and passed so payload and
key is ok).
but
Extracting it all and placing it behind a provider API makes a lot of
sense, since there needs to be a memcached version for those sites
that have that infrastructure in place. (interested todo a memcached
version)
Ian
> 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-jcs.patch, 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279-provider.patch
Moved all config into a Guice Module.
for providers from
https://source.sakaiproject.org/contrib/tfd/trunk/shindig-cacheproviders r50237
EhCache Works.
Apache JCS is detecting some private non serializable keys and so does not work.
At the moment, I am not intending to do more work on this patch.
> 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-provider.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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603648#action_12603648 ]
Kevin Brown commented on SHINDIG-279:
-------------------------------------
Agreed -- do you have any interest in doing this yourself? We'd love to have that sort of flexibility here.
> 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-jcs.patch, 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.
Re: [jira] Commented: (SHINDIG-279) Configurable and clusterable cache for Gadgets server
Posted by Ian Boston <ie...@tfd.co.uk>.
Oh sorry, yes, definitely should be using JCS, no question (IMHO). I
should have looked there first. Sorry, I have used ehcache before so
it was easy. I will refactor for JCS, and try and address the other
issues.
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.
>
Re: [jira] Commented: (SHINDIG-279) Configurable and clusterable cache for Gadgets server
Posted by Kevin Brown <et...@google.com>.
On Sun, May 18, 2008 at 3:13 PM, Ian Boston <ie...@tfd.co.uk> 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 <ie...@tfd.co.uk> 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.
>>>>
>>>>
>>>>
>>>
>
Re: [jira] Commented: (SHINDIG-279) Configurable and clusterable cache for Gadgets server
Posted by Ian Boston <ie...@tfd.co.uk>.
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 <ie...@tfd.co.uk> 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.
>>>
>>>
>>
Re: [jira] Commented: (SHINDIG-279) Configurable and clusterable cache for Gadgets server
Posted by Kevin Brown <et...@google.com>.
On Sun, May 18, 2008 at 2:12 PM, Ian Boston <ie...@tfd.co.uk> 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.
>>
>>
>
Re: [jira] Commented: (SHINDIG-279) Configurable and clusterable cache for Gadgets server
Posted by Ian Boston <ie...@tfd.co.uk>.
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.
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.
>
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603815#action_12603815 ]
Ian Boston commented on SHINDIG-279:
------------------------------------
I will have a go tomorrow, 11 June, I have some time available.
> 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-jcs.patch, 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.
[jira] Commented: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597848#action_12597848 ]
Kevin Brown commented on SHINDIG-279:
-------------------------------------
The option to use a shared cache is definitely within the scope of Shindig (as long as it doesn't require firing it up to start). We really don't want to make it so that you have to know how to write Java to use Shindig, and that means providing production-worthy implementations of all facilities without changing anything other than configuration.
> 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: SHINDIG-279-jcs.patch
A JCS version,
However.
Even thoough the HttpResponse is now serializable and passes a seialization test, it does not come out of JCS the same as it went in, since some of the expires tests dont work any more. I have tested the serialization down to the element level with ObjectInputStream and ObjectOutputStream, which all pass Ok.
However, when I run the the BasicHttpCacheTest, it fails on some of the methods. This needs more work to make it go.
> 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-jcs.patch, 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.
[jira] Updated: (SHINDIG-279) Configurable and clusterable cache
for Gadgets server
Posted by "Ian Boston (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ian Boston updated SHINDIG-279:
-------------------------------
Attachment: (was: SHINDIG-279-provider.patch)
> 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-provider.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.